•	目录

企业集成模式：设计、构建和部署消息传递解决方案
作者： 格雷戈尔·霍普、鲍比·伍尔夫
出版商	：艾迪生韦斯利
发布日期	： 2003 年 10 月 10 日
国际标准书号	：0-321-20068-3
页数	: 736

• 您想使用一致的视觉符号来绘制集成解决方案吗？查看前盖内部。

• Would you like to use a con­sist­ent visual nota­tion for draw­ing in­teg­ra­tion solu­tions? Look inside the front cover.

• 您想利用异步系统的强大功能而不陷入陷阱吗？请参阅简介中的“异步思考”。

• Do you want to har­ness the power of asyn­chron­ous sys­tems without get­ting caught in the pit­falls? See "Think­ing Asyn­chron­ously" in the In­tro­duc­tion.

• 您想知道哪种类型的应用程序集成最适合您的目的吗？请参阅第 2 章，集成样式。

• Do you want to know which style of ap­plic­a­tion in­teg­ra­tion is best for your pur­poses? See Chapter 2, In­teg­ra­tion Styles.

• 您想学习并发处理消息的技术吗？请参阅第 10 章，竞争消费者和消息调度程序。

• Do you want to learn tech­niques for pro­cess­ing mes­sages con­cur­rently? See Chapter 10, Com­pet­ing Con­sumers and Mes­sage Dis­patcher.

• 您想了解如何跟踪跨分布式系统流动的异步消息吗？请参阅第 11 章，消息历史记录和消息存储。

• Do you want to learn how you can track asyn­chron­ous mes­sages as they flow across dis­trib­uted sys­tems? See Chapter 11, Mes­sage His­tory and Mes­sage Store.

• 您是否想了解如何使用 Java Web 服务、.NET 消息队列和基于 TIBCO 的发布-订阅架构来实现使用集成模式设计的系统？请参阅第 9 章，插曲：组合消息。

• Do you want to un­der­stand how a system de­signed using in­teg­ra­tion pat­terns can be im­ple­men­ted using Java Web ser­vices, .NET mes­sage queuing, and a TIBCO-based pub­lish-sub­scribe ar­chi­tec­ture? See Chapter 9, In­ter­lude: Com­posed Mes­saging.

经验丰富的专家 Gregor Hohpe 和 Bobby Woolf 利用多年的实践经验，展示了异步消息传递如何被证明是企业集成成功的最佳策略。然而，构建和部署消息传递解决方案给开发人员带来了许多问题。企业集成模式提供了包含65 种模式的宝贵目录，以及实际的解决方案，这些解决方案展示了消息传递的强大功能，并帮助您为企业设计有效的消息传递解决方案。

Util­iz­ing years of prac­tical ex­per­i­ence, seasoned ex­perts Gregor Hohpe and Bobby Woolf show how asyn­chron­ous mes­saging has proven to be the best strategy for en­ter­prise in­teg­ra­tion suc­cess. How­ever, build­ing and de­ploy­ing mes­saging solu­tions presents a number of prob­lems for de­ve­lopers. En­ter­prise In­teg­ra­tion Pat­terns provides an in­valu­able cata­log of sixty-five pat­terns, with real-world solu­tions that demon­strate the for­mid­able of mes­saging and help you to design ef­fect­ive mes­saging solu­tions for your en­ter­prise.

作者还提供了涵盖各种不同集成技术的示例，例如 JMS、MSMQ、TIBCO ActiveEnterprise、Microsoft BizTalk、SOAP 和 XSL。描述债券交易系统的案例研究阐释了实践中的模式，本书介绍了新兴标准，并洞察了企业集成的未来可能会发生什么。

The au­thors also in­clude ex­amples cov­er­ing a vari­ety of dif­fer­ent in­teg­ra­tion tech­no­lo­gies, such as JMS, MSMQ, TIBCO Act­iveEn­ter­prise, Mi­crosoft BizTalk, SOAP, and XSL. A case study de­scrib­ing a bond trad­ing system il­lus­trates the pat­terns in prac­tice, and the book offers a look at emer­ging stand­ards, as well as in­sights into what the future of en­ter­prise in­teg­ra­tion might hold.

本书提供了一致的词汇和视觉符号框架来描述跨多种技术的大规模集成解决方案。它还详细探讨了异步消息传递架构的优点和局限性。作者提供了有关设计将应用程序连接到消息传递系统的代码的实用建议，并提供了广泛的信息来帮助您确定何时发送消息、如何将其路由到正确的目的地以及如何监视消息传递系统的运行状况。如果您想了解如何管理、监控和维护正在使用的消息系统，请阅读本书。

This book provides a con­sist­ent vocab­u­lary and visual nota­tion frame­work to de­scribe large-scale in­teg­ra­tion solu­tions across many tech­no­lo­gies. It also ex­plores in detail the ad­vant­ages and lim­it­a­tions of asyn­chron­ous mes­saging ar­chi­tec­tures. The au­thors present prac­tical advice on design­ing code that con­nects an ap­plic­a­tion to a mes­saging system, and provide ex­tens­ive in­form­a­tion to help you de­term­ine when to send a mes­sage, how to route it to the proper des­tin­a­tion, and how to mon­itor the health of a mes­saging system. If you want to know how to manage, mon­itor, and main­tain a mes­saging system once it is in use, get this book.

版权

Copyright

制造商和销售商用来区分其产品的许多名称都被称为商标。如果这些名称出现在本书中，并且 Addison-Wesley 知道商标声明，则这些名称均以首字母大写或全部大写印刷。

Many of the des­ig­na­tions used by man­u­fac­tur­ers and sellers to dis­tin­guish their products are claimed as trade­marks. Where those des­ig­na­tions appear in this book, and Ad­dison-Wesley was aware of a trade­mark claim, the des­ig­na­tions have been prin­ted with ini­tial cap­ital let­ters or in all cap­it­als.

作者和出版商在准备本书的过程中非常谨慎，但没有做出任何形式的明示或暗示的保证，并且对错误或遗漏不承担任何责任。对于因使用此处包含的信息或程序而产生的偶然或间接损害，我们不承担任何责任。

The au­thors and pub­lisher have taken care in the pre­par­a­tion of this book, but make no ex­pressed or im­plied war­ranty of any kind and assume no re­spons­ib­il­ity for errors or omis­sions. No li­ab­il­ity is as­sumed for in­cid­ental or con­sequen­tial dam­ages in con­nec­tion with or arising out of the use of the in­form­a­tion or pro­grams con­tained herein.

出版商在批量购买和特价销售时提供本书折扣。获取更多资讯，请联系：

The pub­lisher offers dis­counts on this book when ordered in quant­ity for bulk pur­chases and spe­cial sales. For more in­form­a­tion, please con­tact:

     美国企业和政府销售

     (800) 382-3419

     corpsales@pearsontechgroup.com

     U.S. Cor­por­ate and Gov­ern­ment Sale

     (800) 382-3419

     corp­sales@pear­sontech­group.com

对于美国境外的销售，请联系：

For sales out­side of the U.S., please con­tact:

     国际销售

     (317) 581-3793   

     International@pearsontechgroup.com

     In­ter­na­tional Sales

     (317) 581-3793   

     in­ter­na­tional@pear­sontech­group.com

访问 Addison-Wesley 网站：www.awprofessional.com

Visit Ad­dison-Wesley on the Web: www.aw­pro­fes­sional.com

美国国会图书馆出版数据编目

Lib­rary of Con­gress Cata­loging-in-Pub­lic­a­tion Data

霍普，格雷戈尔。

   企业集成模式：设计、构建和部署消息传递解决 

 方案/Gregor Hohpe、Bobby Woolf。

        p。厘米。

   包括参考书目和索引。

   ISBN 0-321-20068-3

   1. 电信消息处理。2.管理信息 

 系统。I.伍尔夫，鲍比。二. 标题。



 TK5102.5.H5882 2003

 005.7'136dc22

                                                                     2003017989

Hohpe, Gregor.

   En­ter­prise in­teg­ra­tion pat­terns : design­ing, build­ing, and de­ploy­ing mes­saging 

 solu­tions / Gregor Hohpe, Bobby Woolf.

        p. cm.

   In­cludes bib­li­o­graph­ical ref­er­ences and index.

   ISBN 0-321-20068-3

   1. Tele­com­mu­nic­a­tion­Mes­sage pro­cess­ing. 2. Man­age­ment in­form­a­tion 

 sys­tems. I. Woolf, Bobby. II. Title.



 TK5102.5.H5882 2003

 005.7'136d­c22

                                                                     2003017989

版权所有 © 2004 培生教育公司

Copy­right © 2004 by Pear­son Edu­ca­tion, Inc.

版权所有。未经出版商事先同意，不得以任何形式或任何方式（电子、机械、复印、录制或其他方式）复制、存储或传播本出版物的任何部分。美国印刷。加拿大同步出版。

All rights re­served. No part of this pub­lic­a­tion may be re­pro­duced, stored in a re­trieval system, or trans­mit­ted, in any form, or by any means, elec­tronic, mech­an­ical, pho­to­copy­ing, re­cord­ing, or oth­er­wise, without the prior con­sent of the pub­lisher. Prin­ted in the United States of Amer­ica. Pub­lished sim­ul­tan­eously in Canada.

有关获得使用本作品材料的许可的信息，请向以下地址提交书面请求：

For in­form­a­tion on ob­tain­ing per­mis­sion for use of ma­ter­ial from this work, please submit a writ­ten re­quest to:

Pearson Education, Inc.

权利和合同部 75

Arlington Street, Suite 300

Boston, MA 02116 传真：

(617) 848-7047

Pear­son Edu­ca­tion, Inc.

Rights and Con­tracts De­part­ment

75 Ar­ling­ton Street, Suite 300

Boston, MA 02116

Fax: (617) 848-7047

文字印在再生纸上

Text prin­ted on re­cycled paper

1 2 3 4 5 6 7 8 9 10CRS0706050403

1 2 3 4 5 6 7 8 9 10CRS0706050403

首次印刷，2003 年 10 月

First print­ing, Oc­to­ber 2003

奉献精神

Dedication

致我的家人和所有在我从书本“紧缩模式”中走出来后仍然记得我的朋友

To my family and all my friends who still re­mem­ber me after I emerged from book "crunch mode"

格雷戈尔

Gregor

致我的新婚妻子莎伦

To Sharon, my new wife

鲍比

Bobby

艾迪生-韦斯利签名系列

The Addison-Wesley Signature Series

艾迪生-韦斯利签名系列为读者提供了有关计算机专业人员现代技术最新趋势的实用且权威的信息。该系列基于一个简单的前提：伟大的书籍来自伟大的作者。该系列书籍均由专家顾问、世界级作者亲自挑选。这些专家很自豪能在封面上签名，他们的签名确保这些思想领袖与作者密切合作，确定主题范围、书籍范围、关键内容和整体独特性。专家签名也象征着对读者的承诺：您正在阅读一部未来的经典。

The Ad­dison-Wesley Sig­na­ture Series provides read­ers with prac­tical and au­thor­it­at­ive in­form­a­tion on the latest trends in modern tech­no­logy for com­puter pro­fes­sion­als. The series is based on one simple premise: great books come from great au­thors. Books in the series are per­son­ally chosen by expert ad­visors, world-class au­thors in their own right. These ex­perts are proud to put their sig­na­tures on the covers, and their sig­na­tures ensure that these thought lead­ers have worked closely with au­thors to define topic cov­er­age, book scope, crit­ical con­tent, and over­all unique­ness. The expert sig­na­tures also sym­bol­ize a prom­ise to our read­ers: you are read­ing a future clas­sic.

艾迪生-韦斯利签名系列

The Ad­dison-Wesley Sig­na­ture Series

签名者：肯特·贝克和马丁·福勒

SIGNERS: KENT BECK AND MARTIN FOWLER

Kent Beck开创了以人为本的技术，例如 JUnit、极限编程和软件开发模式。Kent 感兴趣的是通过寻找一种同时满足经济、美学、情感和实践约束的软件开发风格来帮助团队取得好成绩。他的书重点关注软件创建者和用户的生活。

Kent Beck has pi­on­eered people-ori­ented tech­no­lo­gies like JUnit, Ex­treme Pro­gram­ming, and pat­terns for soft­ware de­vel­op­ment. Kent is in­ter­ested in help­ing teams do well by doing good find­ing a style of soft­ware de­vel­op­ment that sim­ul­tan­eously sat­is­fies eco­nomic, aes­thetic, emo­tional, and prac­tical con­straints. His books focus on touch­ing the lives of the cre­at­ors and users of soft­ware.

Martin Fowler是企业应用程序中对象技术的先驱。他最关心的是如何设计好软件。他专注于深入了解如何构建可持续发展的企业软件的核心。他有兴趣在技术细节背后寻找持续多年的模式、实践和原则；这些书十年后应该可以使用。马丁的标准是这些是他希望自己能写的书。

Martin Fowler has been a pi­on­eer of object tech­no­logy in en­ter­prise ap­plic­a­tions. His cent­ral con­cern is how to design soft­ware well. He fo­cuses on get­ting to the heart of how to build en­ter­prise soft­ware that will last well into the future. He is in­ter­ested in look­ing behind the spe­cif­ics of tech­no­lo­gies to the pat­terns, prac­tices, and prin­ciples that last for many years; these books should be usable a decade from now. Martin's cri­terion is that these are books he wished he could write.

系列中的标题

Titles in the Series

测试驱动开发：以

Kent，ISBN：0321146530

Test-Driven De­vel­op­ment: By Ex­ample

Kent Beck, ISBN: 0321146530

企业应用程序架构模式 Martin

Fowler，ISBN：0321127420

Pat­terns of En­ter­prise Ap­plic­a­tion Ar­chi­tec­ture

Martin Fowler, ISBN: 0321127420

超越软件架构：创建和维持获胜解决方案

Luke Hohmann，ISBN：0201775948

Beyond Soft­ware Ar­chi­tec­ture: Cre­at­ing and Sus­tain­ing Win­ning Solu­tions

Luke Hohmann, ISBN: 0201775948

企业集成模式：设计、构建和部署消息传递解决方案

Gregor Hohpe 和 Bobby Woolf，ISBN：0321200683

En­ter­prise In­teg­ra­tion Pat­terns: Design­ing, Build­ing, and De­ploy­ing Mes­saging Solu­tions

Gregor Hohpe and Bobby Woolf, ISBN: 0321200683

欲了解更多信息，请访问该系列网站：www.awprofessional.com

For more in­form­a­tion, check out the series web site at www.aw­pro­fes­sional.com

前言

Foreword

作者：约翰·克鲁皮

by John Crupi

当新技术出现时你会做什么？你学习技术。这正是我所做的。我学习了 J2EE（来自 Sun Microsystems，这似乎是合乎逻辑的选择）。具体来说，我通过阅读规范来关注 EJB 技术（因为还没有书籍）。然而，学习技术只是第一步，真正的目标是学习如何有效地应用技术。平台技术的好处在于它们会限制您执行某些任务。但是，就技术而言，你可以为所欲为，但如果做得不当，常常会遇到麻烦。

What do you do when a new tech­no­logy ar­rives? You learn the tech­no­logy. This is ex­actly what I did. I stud­ied J2EE (being from Sun Mi­crosys­tems, it seemed to be the lo­gical choice). Spe­cific­ally, I fo­cused on the EJB tech­no­logy by read­ing the spe­cific­a­tions (since there were no books yet). Learn­ing the tech­no­logy, how­ever, is just the first stepthe real goal is to learn how to ef­fect­ively apply the tech­no­logy. The nice thing about plat­form tech­no­lo­gies is that they con­strain you to per­form­ing cer­tain tasks. But, as far as the tech­no­logy is con­cerned, you can do whatever you want and quite often get into trouble if you don't do things ap­pro­pri­ately.

在过去 15 年里我看到的一件事是，软件开发人员似乎痴迷于两个领域：编程和设计，或者更具体地说，有效地编程和设计。有很多很棒的书籍告诉您用 Java 和 C# 进行某些编程的最有效方法，但告诉您如何有效设计的却少之又少。这就是本书的用武之地。当 Deepak Alur、Dan Malks 和我撰写《核心 J2EE 模式》时，我们希望帮助 J2EE 开发人员“设计”更好的代码。我们做出的最佳决定是使用模式作为选择的工件。正如 Sun 杰出工程师 James Baty 所说，“模式似乎是设计的最佳点。” 我完全同意，幸运的是，格雷戈尔和鲍比也有同样的感觉。

One thing I've seen in the past 15 years is that there seem to be two areas that soft­ware de­ve­lopers obsess over: pro­gram­ming and designingor more spe­cific­ally, pro­gram­ming and design­ing ef­fect­ively. There are great books out there that tell you the most ef­fi­cient way to pro­gram cer­tain things in Java and C#, but far fewer tell you how to design ef­fect­ively. That's where this book comes in. When Deepak Alur, Dan Malks, and I wrote Core J2EE Pat­terns, we wanted to help J2EE de­ve­lopers "design" better code. The best de­cision we made was to use pat­terns as the ar­ti­fact of choice. As James Baty, a Sun Dis­tin­guished En­gin­eer, puts it, "Pat­terns seem to be the sweet spot of design." I couldn't agree more, and luck­ily for us, Gregor and Bobby feel the same way.

本书重点关注一个热门且不断发展的主题：使用消息传递进行集成。消息传递不仅是集成的关键，而且很可能成为未来几年 Web 服务的主要焦点。如今，Web 服务世界中存在着如此多的噪音，仅仅确定要关注的规范和技术就是一项微妙而复杂的工作。目标保持不变，但是软件可以帮助您解决问题。正如 J2EE 和 .NET 的早期一样，Web 服务还没有太多设计帮助。许多人说 Web 服务只是解决我们现有集成问题的一种新的开放方式，我同意。但是，这并不意味着我们知道如何设计 Web 服务。这就引出了本书的精华。我相信这本书包含了我们设计 Web 服务和其他集成系统所需的许多模式。由于 Web 服务规范仍在争论中，因此 Bobby 和 Gregor 提供许多 Web 服务规范的示例是没有意义的。但是，没关系。当规范成为标准并且我们使用本书中的模式来设计通过这些标准实现的解决方案时，才会产生真正的回报。那么也许我们可以实现我们的下一个集成目标，即面向服务的架构设计。对于 Bobby 和 Gregor 来说，提供许多 Web 服务规范的示例是没有意义的。但是，没关系。当规范成为标准并且我们使用本书中的模式来设计通过这些标准实现的解决方案时，才会产生真正的回报。那么也许我们可以实现我们的下一个集成目标，即面向服务的架构设计。对于 Bobby 和 Gregor 来说，提供许多 Web 服务规范的示例是没有意义的。但是，没关系。当规范成为标准并且我们使用本书中的模式来设计通过这些标准实现的解决方案时，才会产生真正的回报。那么也许我们可以实现我们的下一个集成目标，即面向服务的架构设计。

This book fo­cuses on a hot and grow­ing topic: in­teg­ra­tion using mes­saging. Not only is mes­saging key to in­teg­ra­tion, but it will most likely be the pre­dom­in­ant focus in Web ser­vices for years to come. There is so much noise today in the Web ser­vices world, it's a del­ic­ate and com­plex en­deavor just to identify the spe­cific­a­tions and tech­no­lo­gies to focus on. The goal re­mains the same, how­ever­soft­ware helps you solve a prob­lem. Just as in the early days of J2EE and .NET, there is not a lot of design help out there yet for Web ser­vices. Many people say Web ser­vices is just a new and open way to solve our ex­ist­ing in­teg­ra­tion prob­lem­sand I agree. But, that doesn't mean we know how to design Web ser­vices. And that brings us to the gem of this book. I be­lieve this book has many of the pat­terns we need to design Web ser­vices and other in­teg­ra­tion sys­tems. Be­cause the Web ser­vice spe­cific­a­tions are still bat­tling it out, it wouldn't have made sense for Bobby and Gregor to provide ex­amples of many of the Web ser­vice spe­cific­a­tions. But, that's okay. The real payoff will result when the spe­cific­a­tions become stand­ards and we use the pat­terns in this book to design for those solu­tions that are real­ized by these stand­ards. Then maybe we can real­ize our next in­teg­ra­tion goal of design­ing for ser­vice-ori­ented ar­chi­tec­tures.

阅读这本书并将其放在身边。它将让您的软件职业生涯永无止境。

Read this book and keep it by your side. It will en­hance your soft­ware career to no end.

约翰·克鲁皮·贝塞斯达(John Crupi

Bethesda)，医学博士 2003 年

8 月

John Crupi

Beth­esda, MD

August 2003

前言

Foreword

马丁·福勒

by Martin Fowler

当我在写《企业应用程序架构模式》一书时，我很幸运在位于罗利达勒姆的 Kyle 办公室举行的一些非正式研讨会上得到了 Kyle Brown 和 Rachel Reinitz 的深入评论。在这些会议期间，我们意识到我的工作中的一个很大的差距是异步消息系统。

While I was work­ing on my book Pat­terns of En­ter­prise Ap­plic­a­tion Ar­chi­tec­ture, I was lucky to get some in-depth review from Kyle Brown and Rachel Rein­itz at some in­formal work­shops at Kyle's office in Raleigh-Durham. During these ses­sions, we real­ized that a big gap in my work was asyn­chron­ous mes­saging sys­tems.

我的书中有很多空白，我从来没有打算把它作为企业开发模式的完整集合。但异步消息传递方面的差距尤为重要，因为我们相信异步消息传递将在企业软件开发中发挥越来越重要的作用，特别是在集成方面。集成很重要，因为应用程序不能彼此隔离。我们需要一些技术，使我们能够采用从未设计为互操作的应用程序并打破“烟囱”，这样我们就可以获得比单个应用程序所能提供的更大的好处。

There are many gaps in my book, and I never in­ten­ded it to be a com­plete col­lec­tion of pat­terns for en­ter­prise de­vel­op­ment. But the gap on asyn­chron­ous mes­saging is par­tic­u­larly im­port­ant be­cause we be­lieve that asyn­chron­ous mes­saging will play an in­creas­ingly im­port­ant role in en­ter­prise soft­ware de­vel­op­ment, par­tic­u­larly in in­teg­ra­tion. In­teg­ra­tion is im­port­ant be­cause ap­plic­a­tions cannot live isol­ated from each other. We need tech­niques that allow us to take ap­plic­a­tions that were never de­signed to in­ter­op­er­ate and break down the stovepipes so we can gain a greater be­ne­fit than the in­di­vidual ap­plic­a­tions can offer us.

各种技术都有望解决集成难题。我们都得出结论，消息传递是最有前途的技术。我们面临的挑战是传达如何有效地进行消息传递。其中最大的挑战是消息本质上是异步的，并且您在异步世界中使用的设计方法存在显着差异。

Vari­ous tech­no­lo­gies have been around that prom­ise to solve the in­teg­ra­tion puzzle. We all con­cluded that mes­saging is the tech­no­logy that car­ries the greatest prom­ise. The chal­lenge we faced was to convey how to do mes­saging ef­fect­ively. The biggest chal­lenge in this is that mes­sages are by their nature asyn­chron­ous, and there are sig­ni­fic­ant dif­fer­ences in the design ap­proaches that you use in an asyn­chron­ous world.

我没有空间、精力，或者坦率地说没有知识来在企业应用程序架构模式中正确讨论这个主题。但我们想出了一个更好的解决方案来解决这个问题：找到其他有能力的人。我们追捕了格雷戈尔和鲍比，他们接受了挑战。结果就是您将要阅读的书。

I didn't have space, energy, or frankly the know­ledge to cover this topic prop­erly in Pat­terns of En­ter­prise Ap­plic­a­tion Ar­chi­tec­ture. But we came up with a better solu­tion to this gap: find someone else who could. We hunted down Gregor and Bobby, and they took up the chal­lenge. The result is the book you're about to read.

我对他们所做的工作感到高兴。如果您已经使用过消息传递系统，那么本书将系统化您和其他人已经通过艰苦的方式学到的大部分知识。如果您即将使用消息传递系统，那么无论您必须使用哪种消息传递技术，本书都将提供非常宝贵的基础。

I'm de­lighted with the job that they have done. If you've already worked with mes­saging sys­tems, this book will sys­tem­at­ize much of the know­ledge that you and others have already learned the hard way. If you are about to work with mes­saging sys­tems, this book will provide a found­a­tion that will be in­valu­able no matter which mes­saging tech­no­logy you have to work with.

Martin Fowler

梅尔罗斯，马萨诸塞州 2003 年

8 月

Martin Fowler

Mel­rose, MA

August 2003

前言

Preface

这是一本关于使用消息传递进行企业集成的书。它不记录任何特定的技术或产品。相反，它是为使用各种消息传递产品和技术的开发人员和集成商而设计的，例如

This is a book about en­ter­prise in­teg­ra­tion using mes­saging. It does not doc­u­ment any par­tic­u­lar tech­no­logy or product. Rather, it is de­signed for de­ve­lopers and in­teg­rat­ors using a vari­ety of mes­saging products and tech­no­lo­gies, such as

• IBM (WebSphere MQ Family)、Microsoft (BizTalk)、TIBCO、WebMethods、SeeBeyond、Vitria 等供应商提供的面向消息的中间件 (MOM) 和 EAI 套件。

• Mes­sage-ori­ented mid­dle­ware (MOM) and EAI suites offered by vendors such as IBM (Web­Sphere MQ Family), Mi­crosoft (BizTalk), TIBCO, Web­Meth­ods, See­Bey­ond, Vitria, and others.

• Java 消息服务 (JMS) 实现已合并到商业和开源 J2EE 应用程序服务器以及独立产品中。

• Java Mes­sage Ser­vice (JMS) im­ple­ment­a­tions in­cor­por­ated into com­mer­cial and open source J2EE ap­plic­a­tion serv­ers as well as stan­dalone products.

• Microsoft 的消息队列 (MSMQ)，可通过多个 API 访问，包括 Microsoft .NET 中的 System.Messaging 库。

• Mi­crosoft's Mes­sage Queuing (MSMQ), ac­cess­ible through sev­eral APIs, in­clud­ing the System.Mes­saging lib­rar­ies in Mi­crosoft .NET.

• 支持异步 Web 服务（例如 WS-ReliableMessaging）和相关 API（例如 Sun Microsystems 的 Java API for XML Messaging (JAXM) 或 Microsoft 的 Web Services Extensions (WSE)）的新兴 Web 服务标准。

• Emer­ging Web ser­vices stand­ards that sup­port asyn­chron­ous Web ser­vices (for ex­ample, WS-Re­li­ableMes­saging) and the as­so­ci­ated APIs such as Sun Mi­crosys­tems' Java API for XML Mes­saging (JAXM) or Mi­crosoft's Web Ser­vices Ex­ten­sions (WSE).

企业集成不仅仅是创建具有分布式网络的单个应用程序层架构，使单个应用程序能够分布在多台计算机上。分布式应用程序中的一层无法自行运行，而集成应用程序是独立的程序，每个程序都可以自行运行，但通过以松散耦合的方式相互协调来发挥作用。消息传递使多个应用程序能够使用“发送后忘记”的方法通过网络交换数据或命令。这允许呼叫者发送信息并在消息系统传输信息的同时立即继续其他工作。或者，稍后可以通过回调通知调用者结果。异步调用和回调可以使设计比同步方法更复杂，但是异步调用可以重试直到成功，这使得通信更加可靠。异步消息传递还具有其他一些优势，例如请求限制和负载平衡。

En­ter­prise in­teg­ra­tion goes beyond cre­at­ing a single ap­plic­a­tion with a dis­trib­uted n-tier ar­chi­tec­ture, which en­ables a single ap­plic­a­tion to be dis­trib­uted across sev­eral com­puters. Whereas one tier in a dis­trib­uted ap­plic­a­tion cannot run by itself, in­teg­rated ap­plic­a­tions are in­de­pend­ent pro­grams that can each run by them­selves, yet that func­tion by co­ordin­at­ing with each other in a loosely coupled way. Mes­saging en­ables mul­tiple ap­plic­a­tions to ex­change data or com­mands across the net­work using a "send and forget" ap­proach. This allows the caller to send the in­form­a­tion and im­me­di­ately go on to other work while the in­form­a­tion is trans­mit­ted by the mes­saging system. Op­tion­ally, the caller can later be no­ti­fied of the result through a call­back. Asyn­chron­ous calls and call­backs can make a design more com­plex than a syn­chron­ous ap­proach, but an asyn­chron­ous call can be re­tried until it suc­ceeds, which makes the com­mu­nic­a­tion much more re­li­able. Asyn­chron­ous mes­saging also en­ables sev­eral other ad­vant­ages, such as throt­tling of re­quests and load bal­an­cing.

谁应该读这本书

Who Should Read This Book

本书旨在帮助应用程序开发人员和系统集成商使用面向消息的集成工具连接应用程序：

This book is de­signed to help ap­plic­a­tion de­ve­lopers and system in­teg­rat­ors con­nect ap­plic­a­tions using mes­sage-ori­ented in­teg­ra­tion tools:

• 设计和构建需要与其他应用程序集成的复杂企业应用程序的应用程序架构师和开发人员。我们假设您正在使用现代企业应用程序平台（例如 Java 2 平台企业版 (J2EE) 或 Microsoft .NET Framework）开发应用程序。本书将帮助您将应用程序连接到消息传递层并与其他应用程序交换信息。本书重点关注应用程序的集成，而不是构建应用程序；为此，我们向您推荐Martin Fowler 的《企业应用程序架构模式》 。

• Ap­plic­a­tion ar­chi­tects and de­ve­lopers who design and build com­plex en­ter­prise ap­plic­a­tions that need to in­teg­rate with other ap­plic­a­tions. We assume that you're de­vel­op­ing your ap­plic­a­tions using a modern en­ter­prise ap­plic­a­tion plat­form such as the Java 2 Plat­form, En­ter­prise Edi­tion (J2EE), or the Mi­crosoft .NET Frame­work. This book will help you con­nect the ap­plic­a­tion to a mes­saging layer and ex­change in­form­a­tion with other ap­plic­a­tions. This book fo­cuses on the in­teg­ra­tion of ap­plic­a­tions, not on build­ing ap­plic­a­tions; for that, we refer you to Pat­terns of En­ter­prise Ap­plic­a­tion Ar­chi­tec­ture by Martin Fowler.

• 设计和构建连接打包或自定义应用程序的集成解决方案的集成架构师和开发人员。本组中的大多数读者都具有使用 IBM WebSphere MQ、TIBCO、WebMethods、SeeBeyond 或 Vitria 等众多商业集成工具之一的经验，这些工具结合了本书中介绍的许多模式。本书可帮助您理解基本概念，并使用独立于供应商的词汇做出自信的设计决策。

• In­teg­ra­tion ar­chi­tects and de­ve­lopers who design and build in­teg­ra­tion solu­tions con­nect­ing pack­aged or custom ap­plic­a­tions. Most read­ers in this group will have ex­per­i­ence with one of the many com­mer­cial in­teg­ra­tion tools like IBM Web­Sphere MQ, TIBCO, Web­Meth­ods, See­Bey­ond, or Vitria, which in­cor­por­ate many of the pat­terns presen­ted in this book. This book helps you un­der­stand the un­der­ly­ing con­cepts and make con­fid­ent design de­cisions using a vendor-in­de­pend­ent vocab­u­lary.

• 企业架构师必须维护企业中软件和硬件资产的“全局”视图。本书提供了一致的词汇和图形符号来描述可能跨越多种技术或单点解决方案的大规模集成解决方案。这种语言也是企业架构师与集成和应用程序架构师和开发人员之间有效沟通的关键推动者。

• En­ter­prise ar­chi­tects who have to main­tain the "big pic­ture" view of the soft­ware and hard­ware assets in an en­ter­prise. This book presents a con­sist­ent vocab­u­lary and graph­ical nota­tion to de­scribe large-scale in­teg­ra­tion solu­tions that may span many tech­no­lo­gies or point solu­tions. This lan­guage is also a key en­a­bler for ef­fi­cient com­mu­nic­a­tion between the en­ter­prise ar­chi­tect and the in­teg­ra­tion and ap­plic­a­tion ar­chi­tects and de­ve­lopers.

你将学到什么

What You Will Learn

本书并不试图为企业应用程序集成提供商业案例；而是试图为企业应用程序集成提供商业案例。重点是如何使其发挥作用。您将通过了解以下内容来学习如何集成企业应用程序：

This book does not at­tempt to make a busi­ness case for en­ter­prise ap­plic­a­tion in­teg­ra­tion; the focus is on how to make it work. You will learn how to in­teg­rate en­ter­prise ap­plic­a­tions by un­der­stand­ing the fol­low­ing:

• 与其他集成技术相比，异步消息传递的优点和局限性。

• The ad­vant­ages and lim­it­a­tions of asyn­chron­ous mes­saging as com­pared to other in­teg­ra­tion tech­niques.

• 如何确定应用程序需要的消息通道，如何控制多个消费者是否可以接收同一消息，以及如何处理无效消息。

• How to de­term­ine the mes­sage chan­nels your ap­plic­a­tions will need, how to con­trol whether mul­tiple con­sumers can re­ceive the same mes­sage, and how to handle in­valid mes­sages.

• 何时发送消息、消息应包含什么内容以及如何使用特殊消息属性。

• When to send a mes­sage, what it should con­tain, and how to use spe­cial mes­sage prop­er­ties.

• 即使发送者不知道最终目的地在哪里，如何将消息路由到最终目的地。

• How to route a mes­sage to its ul­ti­mate des­tin­a­tion even when the sender does not know where that is.

• 当发送者和接收者不同意通用格式时如何转换消息。

• How to con­vert mes­sages when the sender and re­ceiver do not agree on a common format.

• 如何设计将应用程序连接到消息传递系统的代码。

• How to design the code that con­nects an ap­plic­a­tion to the mes­saging system.

• 作为企业的一部分使用后如何管理和监控消息传递系统。

• How to manage and mon­itor a mes­saging system once it's in use as part of the en­ter­prise.

本书未涵盖的内容

What This Book Does Not Cover

我们认为，任何标题中带有“企业”一词的书都可能属于以下三类之一。首先，本书可能试图涵盖主题的全部内容，但被迫停止提供有关如何实施实际解决方案的详细指导。其次，这本书可能会提供有关开发实际解决方案的具体实践指导，但被迫限制其所涉及的主题领域的范围。第三，这本书可能试图做到这两点，但很可能永远不会完成，否则出版得太晚，以至于变得无关紧要。我们选择了第二个选择，并希望创建一本能够帮助人们创建更好的集成解决方案的书，尽管我们不得不限制这本书的范围。我们很想讨论但为了不落入第三类陷阱而必须排除的主题包括安全性、复杂数据映射、工作流、规则引擎、可扩展性和鲁棒性以及分布式事务处理（XA、Tuxedo 和喜欢）。我们选择异步消息传递作为本书的重点，因为它充满了有趣的设计问题和权衡，并从各个集成供应商提供的许多实现中提供了清晰的抽象。

We be­lieve that any book sport­ing the word "en­ter­prise" in the title is likely to fall into one of three cat­egor­ies. First, the book might at­tempt to cover the whole breadth of the sub­ject matter but is forced to stop short of de­tailed guid­ance on how to im­ple­ment actual solu­tions. Second, the book might provide spe­cific hands-on guid­ance on the de­vel­op­ment of actual solu­tions but is forced to con­strain the scope of the sub­ject area it ad­dresses. Third, the book might at­tempt to do both but is likely never to be fin­ished or else to be pub­lished so late as to be ir­rel­ev­ant. We opted for the second choice and hope­fully cre­ated a book that helps people create better in­teg­ra­tion solu­tions even though we had to limit the scope of the book. Topics that we would have loved to dis­cuss but had to ex­clude in order not to fall into the cat­egory-three trap in­clude se­cur­ity, com­plex data map­ping, work­flow, rule en­gines, scalab­il­ity and ro­bust­ness, and dis­trib­uted trans­ac­tion pro­cess­ing (XA, Tuxedo, and the like). We chose asyn­chron­ous mes­saging as the em­phasis for this book be­cause it is full of in­ter­est­ing design issues and trade-offs, and provides a clean ab­strac­tion from the many im­ple­ment­a­tions provided by vari­ous in­teg­ra­tion vendors.

本书也不是关于特定消息传递或中间件技术的教程。为了强调本书中提出的概念的广泛适用性，我们提供了基于许多不同技术的示例，例如 JMS、MSMQ、TIBCO、BizTalk 和 XSL。然而，我们关注的是设计决策和权衡，而不是工具的细节。如果您有兴趣了解有关这些特定技术的更多信息，请参阅参考书目中引用的书籍之一或众多在线资源之一。

This book is also not a tu­torial on a spe­cific mes­saging or mid­dle­ware tech­no­logy. To high­light the wide ap­plic­ab­il­ity of the con­cepts presen­ted in this book, we in­cluded ex­amples based on a number of dif­fer­ent tech­no­lo­gies, such as JMS, MSMQ, TIBCO, BizTalk, and XSL. How­ever, we focus on the design de­cisions and trade-offs as op­posed to the spe­cif­ics of the tool. If you are in­ter­ested in learn­ing more about any of these spe­cific tech­no­lo­gies, please refer to one of the books ref­er­enced in the bib­li­o­graphy or to one of the many online re­sources.

本书的结构

How This Book Is Organized

正如标题所示，本书的大部分内容由模式集合组成。在没有简单的“一刀切”答案的领域，例如应用程序体系结构、面向对象的设计或基于异步消息传递体系结构的集成解决方案，模式是一种行之有效的捕获专家知识的方法。

As the title sug­gests, the ma­jor­ity of this book con­sists of a col­lec­tion of pat­terns. Pat­terns are a proven way to cap­ture ex­perts' know­ledge in fields where there are no simple "one size fits all" an­swers, such as ap­plic­a­tion ar­chi­tec­ture, object-ori­ented design, or in­teg­ra­tion solu­tions based on asyn­chron­ous mes­saging ar­chi­tec­tures.

每个模式都会提出一个特定的设计问题，讨论围绕该问题的考虑因素，并提出一个平衡各种力量或驱动因素的优雅解决方案。在大多数情况下，解决方案并不是首先想到的方法，而是随着时间的推移在实际使用中不断演变的方法。因此，每种模式都包含了高级集成开发人员和架构师通过反复构建解决方案并从错误中学习而获得的经验基础。这意味着我们并没有“发明”本书中的模式；而是我们“发明”了本书中的模式。模式不是发明的，而是在该领域的实际实践中发现和观察到的。

Each pat­tern poses a spe­cific design prob­lem, dis­cusses the con­sid­er­a­tions sur­round­ing the prob­lem, and presents an el­eg­ant solu­tion that bal­ances the vari­ous forces or drivers. In most cases, the solu­tion is not the first ap­proach that comes to mind, but one that has evolved through actual use over time. As a result, each pat­tern in­cor­por­ates the ex­per­i­ence base that senior in­teg­ra­tion de­ve­lopers and ar­chi­tects have gained by re­peatedly build­ing solu­tions and learn­ing from their mis­takes. This im­plies that we did not "invent" the pat­terns in this book; pat­terns are not in­ven­ted, but rather dis­covered and ob­served from actual prac­tice in the field.

因为模式是从实践者的实际使用中收获的，所以如果您已经使用企业集成工具和异步消息传递架构有一段时间了，那么本书中的许多模式您可能会感到熟悉。然而，即使您已经认识了其中的大部分模式，回顾本书仍然有价值。本书应该验证您对如何使用消息传递来之不易的理解，同时记录您可能不知道的解决方案及其之间关系的详细信息。它还为您提供综合参考，帮助您有效地将知识传授给经验不足的同事。最后，

Be­cause pat­terns are har­ves­ted from prac­ti­tion­ers' actual use, chances are that if you have been work­ing with en­ter­prise in­teg­ra­tion tools and asyn­chron­ous mes­saging ar­chi­tec­tures for some time, many of the pat­terns in this book will seem fa­mil­iar to you. Yet, even if you already re­cog­nize most of these pat­terns, there is still value in re­view­ing this book. This book should val­id­ate your hard-earned un­der­stand­ing of how to use mes­saging while doc­u­ment­ing de­tails of the solu­tions and re­la­tion­ships between them of which you might not have been aware. It also gives you a con­sol­id­ated ref­er­ence to help you pass your know­ledge ef­fect­ively to less-ex­per­i­enced col­leagues. Fi­nally, the pat­tern names give you a common vocab­u­lary to ef­fi­ciently dis­cuss in­teg­ra­tion design al­tern­at­ives with your peers.

本书中的模式适用于各种编程语言和平台。这意味着模式不是剪切和粘贴的代码片段，但您必须针对特定环境实现模式。为了使这种转换更容易，我们添加了各种示例，这些示例展示了使用流行技术（例如 JMS、MSMQ、TIBCO、BizTalk、XSL 等）实现模式的不同方法。我们还提供了一些较大的示例来演示多个模式如何一起发挥作用以形成一个有凝聚力的解决方案。

The pat­terns in this book apply to a vari­ety of pro­gram­ming lan­guages and plat­forms. This means that a pat­tern is not a cut-and-paste snip­pet of code, but you have to real­ize a pat­tern to your spe­cific en­vir­on­ment. To make this trans­la­tion easier, we added a vari­ety of ex­amples that show dif­fer­ent ways of im­ple­ment­ing pat­terns using pop­u­lar tech­no­lo­gies such as JMS, MSMQ, TIBCO, BizTalk, XSL, and others. We also in­cluded a few larger ex­amples to demon­strate how mul­tiple pat­terns play to­gether to form a co­hes­ive solu­tion.

使用异步消息传递架构集成多个应用程序是一个充满挑战且有趣的领域。我们希望您能像我们编写这本书一样喜欢阅读这本书。

In­teg­rat­ing mul­tiple ap­plic­a­tions using an asyn­chron­ous mes­saging ar­chi­tec­ture is a chal­len­ging and in­ter­est­ing field. We hope you enjoy read­ing this book as much as we did writ­ing it.

关于封面图片

About the Cover Picture

马丁·福勒签名系列书籍的共同主题是桥梁的图片。从某种意义上说，我们很幸运，因为什么主题更适合一本关于集成的书呢？数千年来，桥梁帮助连接来自不同海岸、山区和路边的人们。

The common theme for books in the Martin Fowler Sig­na­ture Series is a pic­ture of a bridge. In some sense we lucked out, be­cause what theme would make a better match for a book on in­teg­ra­tion? For thou­sands of years, bridges have helped con­nect people from dif­fer­ent shores, moun­tains, and sides of the road.

我们选择了日本大阪住吉大社的太鼓桥的照片，因为它简单而优雅。作为供奉水手守护神的神社，最初建在水边。有趣的是，填海造地已将水推开，因此今天的神社矗立在内陆近三英里处。新年伊始，约有三百万人参拜这座神社。

We se­lec­ted a pic­ture of the Taiko-bashi Bridge at the Sum­iy­oshi-taisha Shrine in Osaka, Japan, for its simple el­eg­ance and beauty. As a Shinto shrine ded­ic­ated to the guard­ian deity for sail­ors, it was ori­gin­ally erec­ted next to the water. In­ter­est­ingly, land re­clam­a­tion has pushed the water away so that the shrine today stands almost three miles inland. Some three mil­lion people visit this shrine at the be­gin­ning of a new year.

Gregor Hohpe

加利福尼亚



州

旧金山 Bobby Woolf 北卡罗来纳州



罗利2003 年 9 月

www.enterpriseintegrationpatterns.com

Gregor Hohpe

San Fran­cisco, Cali­for­nia



Bobby Woolf

Raleigh, North Car­o­lina



Septem­ber 2003

www.en­ter­pri­sein­teg­ra­tion­pat­terns.com

卡尔·萨根博士的先锋牌匾

The Pi­on­eer Plaque by Dr. Carl Sagan

给外星生命形式的信息。

A mes­sage to ex­tra­ter­re­strial life forms.

致谢

Acknowledgments

与大多数书籍一样，《企业集成模式》已经酝酿了很长时间。撰写基于消息的集成模式的想法可以追溯到 2001 年夏天，当时 Martin Fowler 正在研究企业应用程序架构模式（ EAA 的 P） 。当时，凯尔·布朗 (Kyle Brown) 突然意识到，虽然EAA 的 P讨论了很多如何创建应用程序，仅简单介绍了如何集成它们。这个想法是马丁和凯尔之间一系列会议的起点，其中包括雷切尔·雷尼茨、约翰·克鲁皮和马克·韦策尔。Bobby 于 2001 年秋季加入了这些讨论，Gregor 于 2002 年初加入。第二年夏天，该小组提交了两篇论文供程序模式语言 (PLoP) 会议审查，其中一篇由 Bobby 和 Kyle 共同撰写，另一篇由 Gregor 撰写。会议结束后，凯尔和马丁重新专注于他们自己的书籍项目，而格雷戈尔和鲍比合并了他们的论文，形成了这本书的基础。同时，www.enterpriseintegrationpatterns.com网站上线后，世界各地的集成架构师和开发人员都可以参与内容的快速发展。在写这本书的过程中，格雷戈尔和鲍比邀请了贡献者参与这本书的创作。凯尔提出最初的想法大约两年后，最终的手稿到达了出版商。

Like most books, En­ter­prise In­teg­ra­tion Pat­terns has been a long time in the making. The idea of writ­ing about mes­sage-based in­teg­ra­tion pat­terns dates back to the summer of 2001 when Martin Fowler was work­ing on Pat­terns of En­ter­prise Ap­plic­a­tion Ar­chi­tec­ture (P of EAA). At that time, it struck Kyle Brown that while P of EAA talked a lot about how to create ap­plic­a­tions, it touches only briefly on how to in­teg­rate them. This idea was the start­ing point for a series of meet­ings between Martin and Kyle that also in­cluded Rachel Rein­itz, John Crupi, and Mark Weitzel. Bobby joined these dis­cus­sions in the fall of 2001, fol­lowed by Gregor in early 2002. The fol­low­ing summer the group sub­mit­ted two papers for review at the Pat­tern Lan­guages of Pro­grams (PLoP) con­fer­ence, one au­thored jointly by Bobby and Kyle and the other by Gregor. After the con­fer­ence, Kyle and Martin re­fo­cused on their own book pro­jects while Gregor and Bobby merged their papers to form the basis for the book. At the same time, the www.en­ter­pri­sein­teg­ra­tion­pat­terns.com site went live to allow in­teg­ra­tion ar­chi­tects and de­ve­lopers around the world to par­ti­cip­ate in the rapid evol­u­tion of the con­tent. As they worked on the book, Gregor and Bobby in­vited con­trib­ut­ors to par­ti­cip­ate in the cre­ation of the book. About two years after Kyle's ori­ginal idea, the final ma­nu­script ar­rived at the pub­lisher.

本书是社区众多人员共同努力的成果。许多同事和朋友（其中许多人是我们在本书中认识的）提供了示例想法，确保了技术内容的正确性，并给了我们急需的反馈和批评。他们的意见极大地影响了本书的最终形式和内容。我们很高兴承认他们的贡献并对他们的努力表示赞赏。

This book is the result of a com­munity effort in­volving a great number of people. Many col­leagues and friends (many of whom we met through the book effort) provided ideas for ex­amples, en­sured the cor­rect­ness of the tech­nical con­tent, and gave us much needed feed­back and cri­ti­cism. Their input has greatly in­flu­enced the final form and con­tent of the book. It is a pleas­ure for us to ac­know­ledge their con­tri­bu­tions and ex­press our ap­pre­ci­ation for their ef­forts.

凯尔·布​​朗和马丁·福勒为本书奠定了基础，值得特别提及。如果不是 Martin 撰写了EAA 的 P，并且 Kyle 组建了一个小组来讨论消息传递模式以补充 Martin 的书，这本书可能永远不会被写出来。

Kyle Brown and Martin Fowler de­serve spe­cial men­tion for laying the found­a­tion for this book. This book might have never been writ­ten were it not for Martin's writ­ing P of EAA and Kyle's form­ing a group to dis­cuss mes­saging pat­terns to com­ple­ment Martin's book.

我们很幸运有几位贡献者撰写了本书的重要部分：Conrad F. D'Cruz、Sean Neville、Michael J. Rettig 和 Jonathan Simon。他们的章节对这些模式如何在实践中发挥作用提供了额外的视角，从而使本书更加完整。

We were for­tu­nate to have sev­eral con­trib­ut­ors who au­thored sig­ni­fic­ant por­tions of the book: Conrad F. D'Cruz, Sean Neville, Mi­chael J. Rettig, and Jonathan Simon. Their chapters round out the book with ad­di­tional per­spect­ives on how the pat­terns work in prac­tice.

PLoP 2002 会议上我们的作家研讨会参与者是第一批对材料提供实质性反馈的人，帮助我们朝着正确的方向前进：Ali Arsanjani、Kyle Brown、John Crupi、Eric Evans、Martin Fowler、Brian Marick、托比·萨弗、乔纳森·西蒙、比尔·特鲁德尔和马雷克·沃卡奇。

Our writers' work­shop par­ti­cipants at the PLoP 2002 con­fer­ence were the first people to provide sub­stan­tial feed­back on the ma­ter­ial, help­ing to get us going in the right dir­ec­tion: Ali Arsan­jani, Kyle Brown, John Crupi, Eric Evans, Martin Fowler, Brian Marick, Toby Sarver, Jonathan Simon, Bill Trudell, and Marek Vokac.

我们要感谢我们的审稿团队，他们花时间阅读了草稿材料，并向我们提供了宝贵的反馈和建议：

We would like to thank our team of re­view­ers who took the time to read through the draft ma­ter­ial and provided us with in­valu­able feed­back and sug­ges­tions:

理查德·赫尔姆

卢克·霍曼

德拉戈斯·马诺莱斯库

大卫·赖斯

Russ Rufer 和硅谷模式小组

马修·肖特

Richard Helm

Luke Hohmann

Dragos Man­olescu

David Rice

Russ Rufer and the Sil­icon Valley Pat­terns Group

Mat­thew Short

特别感谢 Russ 在硅谷模式小组中参与起草本书草稿。我们要感谢以下成员的努力：Robert Benson、Tracy Bialik、Jeffrey Blake、Azad Bolour、John Brewer、Bob Evans、Andy Farlie、Jeff Glaza、Phil Goodwin、Alan Harriman、Ken Hejmanowski、Deborah Kaddah、Rituraj Kirti 、Jan Looney、Chris Lopez、Jerry Louis、马道洪、Jeff Miller、Stilian Pandev、John Parello、Hema Pillay、Russ Rufer、Rich Smith、Carol Thistlethwaite、Debbie Utley、Walter Vannini、David Vydra 和 Ted Young。

Spe­cial thanks go to Russ for work­shop­ping the book draft in the Sil­icon Valley Pat­terns Group. We would like to thank the fol­low­ing mem­bers for their ef­forts: Robert Benson, Tracy Bialik, Jef­frey Blake, Azad Bolour, John Brewer, Bob Evans, Andy Farlie, Jeff Glaza, Phil Good­win, Alan Har­ri­man, Ken Hej­manowski, De­borah Kaddah, Rituraj Kirti, Jan Looney, Chris Lopez, Jerry Louis, Tao-hung Ma, Jeff Miller, Stilian Pandev, John Parello, Hema Pillay, Russ Rufer, Rich Smith, Carol Thistleth­waite, Debbie Utley, Walter Van­nini, David Vydra, and Ted Young.

我们的公共电子邮件讨论列表允许在www.enterpriseintegrationpatterns.com上发现材料的人们插话并分享他们的想法和想法。Bill Trudell 作为邮件列表最活跃的贡献者获得了特殊荣誉。其他活跃海报包括 Venkateshwar Bommineni、Duncan Cragg、John Crupi、Fokko Degenaar、Shailesh Gosavi、Christian Hall、Ralph Johnson、Paul Julius、Orjan Lundberg、Dragos Manolescu、Rob Mee、Srikanth Narasimhan、Sean Neville、Rob Patton、Kirk Pepperdine、Matthew普赖尔、索米克·拉哈、迈克尔·雷蒂格、弗兰克·绍尔、乔纳森·西蒙、费德里科·斯皮纳齐、兰迪·斯塔福德、马雷克·沃卡奇、乔·沃尔恩斯和马克·韦策尔。

Our public e-mail dis­cus­sion list al­lowed people who dis­covered the ma­ter­ial on www.en­ter­pri­sein­teg­ra­tion­pat­terns.com to chime in and share their thoughts and ideas. Spe­cial honors go to Bill Trudell as the most active con­trib­utor to the mail­ing list. Other active posters in­cluded Ven­katesh­war Bom­min­eni, Duncan Cragg, John Crupi, Fokko De­gen­aar, Shailesh Gosavi, Chris­tian Hall, Ralph John­son, Paul Julius, Orjan Lun­d­berg, Dragos Man­olescu, Rob Mee, Srik­anth Narasim­han, Sean Neville, Rob Patton, Kirk Pep­perdine, Mat­thew Pryor, Somik Raha, Mi­chael Rettig, Frank Sauer, Jonathan Simon, Fe­d­erico Spinazzi, Randy Stafford, Marek Vokac, Joe Walnes, and Mark Weitzel.

我们感谢马丁·福勒 (Martin Fowler) 招待我们观看他的签名系列节目。马丁的认可给了我们完成这项工作所需的信心和精力。

We thank Martin Fowler for host­ing us in his sig­na­ture series. Martin's en­dorse­ment gave us con­fid­ence and the energy re­quired to com­plete this work.

我们感谢约翰·克鲁皮为我们的书撰写前言。他从一开始就观察了这本书的形成，并一直耐心指导，但从未失去幽默感。

We thank John Crupi for writ­ing the fore­word for our book. He has ob­served the book's form­a­tion from the be­gin­ning and has been a pa­tient guide all along without ever losing his sense of humor.

最后，我们非常感谢 Addison-Wesley 的编辑和制作团队，他们由我们的主编辑 Mike Hendrickson 领导，包括我们的制作协调员 Amy Fleischer；我们的项目经理 Kim Arney Mulcahy；我们的文案编辑 Carol J. Lallier；我们的校对员 Rebecca Rider；我们的索引员 Sharon Hilgenberg；以及杰奎琳·杜赛特、约翰·富勒和伯纳德·加夫尼。

Fi­nally, we owe a great deal to the edit­ing and pro­duc­tion team at Ad­dison-Wesley, led by our chief editor, Mike Hendrick­son, and in­clud­ing our pro­duc­tion co­ordin­ator, Amy Fleis­cher; our pro­ject man­ager, Kim Arney Mul­cahy; our copy­ed­itor, Carol J. Lal­lier; our proofreader, Re­becca Rider; our in­dexer, Sharon Hil­gen­berg; as well as Jac­quelyn Doucette, John Fuller, and Bern­ard Gaffney.

我们可能遗漏了一些名字，并且没有给予每个人应有的荣誉，我们深表歉意。但对于所有列出的和未列出的帮助使本书变得更好的人，感谢你们的帮助。我们希望您能像我们一样为这本书感到自豪。

We've likely missed some names and not given every­one the credit they de­serve, and we apo­lo­gize. But to every­one listed and not listed who helped make this book better, thank you for all your help. We hope you can be as proud of this book as we are.

介绍

Introduction

有趣的应用程序很少是孤立存在的。无论您的销售应用程序必须与库存应用程序交互，您的采购应用程序必须连接到拍卖站点，还是您的 PDA 日历必须与公司日历服务器同步，似乎任何应用程序都可以通过与其他应用程序集成来变得更好。

In­ter­est­ing ap­plic­a­tions rarely live in isol­a­tion. Whether your sales ap­plic­a­tion must in­ter­face with your in­vent­ory ap­plic­a­tion, your pro­cure­ment ap­plic­a­tion must con­nect to an auc­tion site, or your PDA's cal­en­dar must syn­chron­ize with the cor­por­ate cal­en­dar server, it seems that any ap­plic­a­tion can be made better by in­teg­rat­ing it with other ap­plic­a­tions.

所有集成解决方案都必须应对一些基本挑战：

All in­teg­ra­tion solu­tions have to deal with a few fun­da­mental chal­lenges:

• 网络不可靠。集成解决方案必须通过网络将数据从一台计算机传输到另一台计算机。与在单台计算机上运行的进程相比，分布式计算必须准备好处理更多的可能问题。通常，要集成的两个系统相隔大洲，它们之间的数据必须通过电话线、LAN 网段、路由器、交换机、公共网络和卫星链路传输。每个步骤都可能导致延迟或中断。

• Net­works are un­re­li­able. In­teg­ra­tion solu­tions have to trans­port data from one com­puter to an­other across net­works. Com­pared to a pro­cess run­ning on a single com­puter, dis­trib­uted com­put­ing has to be pre­pared to deal with a much larger set of pos­sible prob­lems. Often, two sys­tems to be in­teg­rated are sep­ar­ated by con­tin­ents, and data between them has to travel through phone lines, LAN seg­ments, routers, switches, public net­works, and satel­lite links. Each step can cause delays or in­ter­rup­tions.

• 网络很慢。通过网络发送数据比进行本地方法调用慢多个数量级。以与处理单个应用程序相同的方式设计广泛分布的解决方案可能会产生灾难性的性能影响。

• Net­works are slow. Send­ing data across a net­work is mul­tiple orders of mag­nitude slower than making a local method call. Design­ing a widely dis­trib­uted solu­tion the same way you would ap­proach a single ap­plic­a­tion could have dis­as­trous per­form­ance im­plic­a­tions.

• 任何两个应用程序都是不同的。集成解决方案需要在使用不同编程语言、操作平台和数据格式的系统之间传输信息。集成解决方案必须能够与所有这些不同的技术交互。

• Any two ap­plic­a­tions are dif­fer­ent. In­teg­ra­tion solu­tions need to trans­mit in­form­a­tion between sys­tems that use dif­fer­ent pro­gram­ming lan­guages, op­er­at­ing plat­forms, and data formats. An in­teg­ra­tion solu­tion must be able to in­ter­face with all these dif­fer­ent tech­no­lo­gies.

• 改变是不可避免的。应用程序会随着时间的推移而变化。集成解决方案必须跟上所连接的应用程序的变化。集成解决方案很容易陷入变化的雪崩效应中，如果一个系统发生变化，所有其他系统都可能受到影响。集成解决方案需要通过在应用程序之间使用松散耦合来最大限度地减少从一个系统到另一个系统的依赖性。

• Change is in­ev­it­able. Ap­plic­a­tions change over time. An in­teg­ra­tion solu­tion has to keep pace with changes in the ap­plic­a­tions it con­nects. In­teg­ra­tion solu­tions can easily get caught in an ava­lanche effect of changesif one system changes, all other sys­tems may be af­fected. An in­teg­ra­tion solu­tion needs to min­im­ize the de­pend­en­cies from one system to an­other by using loose coup­ling between ap­plic­a­tions.

随着时间的推移，开发人员通过四种主要方法克服了这些挑战：

Over time, de­ve­lopers have over­come these chal­lenges with four main ap­proaches:

虽然所有四种方法基本上解决相同的问题，但每种风格都有其独特的优点和缺点。事实上，应用程序可以使用多种样式进行集成，以便每个集成点都可以利用最适合它的样式。

While all four ap­proaches solve es­sen­tially the same prob­lem, each style has its dis­tinct ad­vant­ages and dis­ad­vant­ages. In fact, ap­plic­a­tions may in­teg­rate using mul­tiple styles such that each point of in­teg­ra­tion takes ad­vant­age of the style that suits it best.

什么是消息传递？

What Is Messaging?

本书讲述如何使用消息传递来集成应用程序。了解消息传递功能的一个简单方法是考虑电话系统。电话呼叫是一种同步通信形式。仅当我拨打电话时对方有空时，我才能与对方通信。另一方面，语音邮件允许异步通信。使用语音信箱，当接收者没有接听时，呼叫者可以给他留言；之后，接收者（在他方便的时候）可以收听在他的邮箱中排队的消息。语音邮件使呼叫者现在可以留言，以便接收者稍后可以收听，这比尝试让呼叫者和接收者同时通话要容易得多。语音邮件将（至少部分）电话捆绑到一条消息中，并将其排队以供以后使用；这本质上就是消息传递的工作原理。

This book is about how to use mes­saging to in­teg­rate ap­plic­a­tions. A simple way to un­der­stand what mes­saging does is to con­sider the tele­phone system. A tele­phone call is a syn­chron­ous form of com­mu­nic­a­tion. I can com­mu­nic­ate with the other party only if the other party is avail­able at the time I place the call. Voice mail, on the other hand, allows asyn­chron­ous com­mu­nic­a­tion. With voice mail, when the re­ceiver does not answer, the caller can leave him a mes­sage; later, the re­ceiver (at his con­veni­ence) can listen to the mes­sages queued in his mail­box. Voice mail en­ables the caller to leave a mes­sage now so that the re­ceiver can listen to it later, which is much easier than trying to get the caller and the re­ceiver on the phone at the same time. Voice mail bundles (at least part of) a phone call into a mes­sage and queues it for later con­sump­tion; this is es­sen­tially how mes­saging works.

消息传递是一种能够实现高速、异步、程序到程序通信并可靠交付的技术。程序通过向彼此发送称为消息的数据包来进行通信。Channel ，也称为队列，是连接程序和传递消息的逻辑路径。通道的行为类似于消息的集合或数组，但可以在多台计算机之间神奇地共享，并且可以由多个应用程序同时使用。发送者或生产者是通过将消息写入通道来发送消息的程序。接收者或消费者是一个通过从通道读取（并删除）消息来接收消息的程序。

Mes­saging is a tech­no­logy that en­ables high-speed, asyn­chron­ous, pro­gram-to-pro­gram com­mu­nic­a­tion with re­li­able de­liv­ery. Pro­grams com­mu­nic­ate by send­ing pack­ets of data called mes­sages to each other. Chan­nels, also known as queues, are lo­gical path­ways that con­nect the pro­grams and convey mes­sages. A chan­nel be­haves like a col­lec­tion or array of mes­sages, but one that is ma­gic­ally shared across mul­tiple com­puters and can be used con­cur­rently by mul­tiple ap­plic­a­tions. A sender or pro­du­cer is a pro­gram that sends a mes­sage by writ­ing the mes­sage to a chan­nel. A re­ceiver or con­sumer is a pro­gram that re­ceives a mes­sage by read­ing (and de­let­ing) it from a chan­nel.

消息本身只是某种数据结构，例如字符串、字节数组、记录或对象。它可以简单地解释为数据、接收方调用的命令的描述或发送方发生的事件的描述。消息实际上包含两部分，标题和正文。标头包含有关消息发送者、消息去向等的元信息；该信息由消息传递系统使用，并且大部分被使用消息的应用程序忽略。身体_包含正在传输的应用程序数据，通常会被消息传递系统忽略。在对话中，当使用消息传递的应用程序开发人员谈论消息时，她通常指的是消息正文中的数据。

The mes­sage itself is simply some sort of data struc­ture­such as a string, a byte array, a record, or an object. It can be in­ter­preted simply as data, as the de­scrip­tion of a com­mand to be in­voked on the re­ceiver, or as the de­scrip­tion of an event that oc­curred in the sender. A mes­sage ac­tu­ally con­tains two parts, a header and a body. The header con­tains meta-in­form­a­tion about the mes­sage­who sent it, where it's going, and so on; this in­form­a­tion is used by the mes­saging system and is mostly ig­nored by the ap­plic­a­tions using the mes­sages. The body con­tains the ap­plic­a­tion data being trans­mit­ted and is usu­ally ig­nored by the mes­saging system. In con­ver­sa­tion, when an ap­plic­a­tion de­ve­loper who is using mes­saging talks about a mes­sage, she's usu­ally re­fer­ring to the data in the body of the mes­sage.

异步消息架构很强大，但需要我们重新思考我们的开发方法。与其他三种集成方法相比，接触过消息传递和消息系统的开发人员相对较少。因此，应用程序开发人员一般不太熟悉该通信平台的习惯用法和特性。

Asyn­chron­ous mes­saging ar­chi­tec­tures are power­ful but re­quire us to re­think our de­vel­op­ment ap­proach. As com­pared to the other three in­teg­ra­tion ap­proaches, re­l­at­ively few de­ve­lopers have had ex­pos­ure to mes­saging and mes­sage sys­tems. As a result, ap­plic­a­tion de­ve­lopers in gen­eral are not as fa­mil­iar with the idioms and pe­cu­li­ar­it­ies of this com­mu­nic­a­tions plat­form.

什么是消息系统？

What Is a Messaging System?

消息传递功能通常由称为消息传递系统或面向消息的中间件的单独软件系统提供（妈妈）。消息传递系统管理消息传递的方式与数据库系统管理数据持久性的方式相同。正如管理员必须使用应用程序数据的架构填充数据库一样，管理员必须使用定义应用程序之间通信路径的通道来配置消息传递系统。然后消息系统协调和管理消息的发送和接收。数据库系统的主要目的是确保每个数据记录都安全地保存，同样，消息传递系统的主要任务是以可靠的方式将消息从发送者的计算机移动到接收者的计算机。

Mes­saging cap­ab­il­it­ies are typ­ic­ally provided by a sep­ar­ate soft­ware system called a mes­saging system or mes­sage-ori­ented mid­dle­ware (MOM). A mes­saging system man­ages mes­saging the way a data­base system man­ages data per­sist­ence. Just as an ad­min­is­trator must pop­u­late the data­base with the schema for an ap­plic­a­tion's data, an ad­min­is­trator must con­fig­ure the mes­saging system with the chan­nels that define the paths of com­mu­nic­a­tion between the ap­plic­a­tions. The mes­saging system then co­ordin­ates and man­ages the send­ing and re­ceiv­ing of mes­sages. The primary pur­pose of a data­base system is to make sure each data record is safely per­sisted, and like­wise the main task of a mes­saging system is to move mes­sages from the sender's com­puter to the re­ceiver's com­puter in a re­li­able fash­ion.

需要消息系统将消息从一台计算机移动到另一台计算机，因为计算机和连接它们的网络本质上是不可靠的。仅仅因为一个应用程序准备好发送数据并不意味着另一应用程序准备好接收数据。即使两个应用程序均已准备就绪，网络也可能无法正常工作或无法正确传输数据。消息传递系统通过反复尝试传输消息直到成功来克服这些限制。理想情况下，消息一次就能成功传输，但情况往往并不理想。

A mes­saging system is needed to move mes­sages from one com­puter to an­other be­cause com­puters and the net­works that con­nect them are in­her­ently un­re­li­able. Just be­cause one ap­plic­a­tion is ready to send data does not mean that the other ap­plic­a­tion is ready to re­ceive it. Even if both ap­plic­a­tions are ready, the net­work may not be work­ing or may fail to trans­mit the data prop­erly. A mes­saging system over­comes these lim­it­a­tions by re­peatedly trying to trans­mit the mes­sage until it suc­ceeds. Under ideal cir­cum­stances, the mes­sage is trans­mit­ted suc­cess­fully on the first try, but cir­cum­stances are often not ideal.

本质上，消息的传输分为五个步骤：

In es­sence, a mes­sage is trans­mit­ted in five steps:

下图说明了这五个传输步骤，每个步骤由计算机执行，以及哪些步骤涉及消息传递系统：

The fol­low­ing figure il­lus­trates these five trans­mis­sion steps, which com­puter per­forms each, and which steps in­volve the mes­saging system:

消息传输步骤

Mes­sage Trans­mis­sion Step-by-Step

该图还说明了两个重要的消息传递概念：

This figure also il­lus­trates two im­port­ant mes­saging con­cepts:

创建、发送、接收和处理步骤可能看起来像是不必要的开销。为什么不简单地将数据传递给接收者呢？通过将数据包装为消息并将其存储在消息传递系统中，应用程序将传递数据的责任委托给消息传递系统。由于数据被包装为原子消息，因此可以重试传递直至成功，并且可以确保接收者可靠地接收到数据的一份副本。

The create, send, re­ceive, and pro­cess steps may seem like un­ne­ces­sary over­head. Why not simply de­liver the data to the re­ceiver? By wrap­ping the data as a mes­sage and stor­ing it in the mes­saging system, the ap­plic­a­tions del­eg­ate to the mes­saging system the re­spons­ib­il­ity of de­liv­er­ing the data. Be­cause the data is wrapped as an atomic mes­sage, de­liv­ery can be re­tried until it suc­ceeds, and the re­ceiver can be as­sured of re­li­ably re­ceiv­ing ex­actly one copy of the data.

为什么使用消息传递？

Why Use Messaging?

现在我们知道什么是消息传递，我们应该问，为什么要使用消息传递？与任何复杂的解决方案一样，没有一个简单的答案。简单的回答是，消息传递比文件传输更直接，比共享，并且比远程。然而，这只是使用消息传递可以获得的优势的开始。

Now that we know what mes­saging is, we should ask, Why use mes­saging? As with any soph­ist­ic­ated solu­tion, there is no one simple answer. The quick answer is that mes­saging is more im­me­di­ate than File Trans­fer, better en­cap­su­lated than Shared Data­base, and more re­li­able than Remote Pro­ced­ure In­voc­a­tion. How­ever, that's just the be­gin­ning of the ad­vant­ages that can be gained using mes­saging.

消息传递的具体好处包括：

Spe­cific be­ne­fits of mes­saging in­clude:

• 远程通讯。消息传递使单独的应用程序能够进行通信和传输数据。驻留在同一进程中的两个对象可以简单地共享内存中的相同数据。将数据发送到另一台计算机要复杂得多，需要将数据从一台计算机复制到另一台计算机。这意味着对象必须是“可序列化的”，也就是说，它们可以转换为可以通过网络发送的简单字节流。消息传递负责此转换，因此应用程序不必担心它。

• Remote Com­mu­nic­a­tion. Mes­saging en­ables sep­ar­ate ap­plic­a­tions to com­mu­nic­ate and trans­fer data. Two ob­jects that reside in the same pro­cess can simply share the same data in memory. Send­ing data to an­other com­puter is a lot more com­plic­ated and re­quires data to be copied from one com­puter to an­other. This means that ob­jects have to be "seri­al­iz­able"that is, they can be con­ver­ted into a simple byte stream that can be sent across the net­work. Mes­saging takes care of this con­ver­sion so that the ap­plic­a­tions do not have to worry about it.

• 平台/语言集成。当通过远程通信连接多个计算机系统时，这些系统可能使用不同的语言、技术和平台，这可能是因为它们是由独立团队随着时间的推移而开发的。集成此类不同的应用程序可能需要一个中间件的中立区域来在应用程序之间进行协商，通常使用最低的共同点，例如格式模糊的平面数据文件。在这些情况下，消息传递系统可以成为应用程序之间的通用翻译器，它可以按照自己的条件与每个人的语言和平台一起工作，但允许它们通过通用的消息传递范式进行通信。这种通用连接性是消息总线的核心图案。

• Plat­form/Lan­guage In­teg­ra­tion. When con­nect­ing mul­tiple com­puter sys­tems via remote com­mu­nic­a­tion, these sys­tems likely use dif­fer­ent lan­guages, tech­no­lo­gies, and plat­forms, per­haps be­cause they were de­ve­loped over time by in­de­pend­ent teams. In­teg­rat­ing such di­ver­gent ap­plic­a­tions can re­quire a neut­ral zone of mid­dle­ware to ne­go­ti­ate between the ap­plic­a­tions, often using the lowest common de­nom­in­at­or­such as flat data files with ob­scure formats. In these cir­cum­stances, a mes­saging system can be a uni­ver­sal trans­lator between the ap­plic­a­tions that works with each one's lan­guage and plat­form on its own terms yet allows them to all to com­mu­nic­ate through a common mes­saging paradigm. This uni­ver­sal con­nectiv­ity is the heart of the Mes­sage Bus pat­tern.

• 异步通信。消息传递支持“发送后忘记”的通信方式。发送方不必等待接收方接收并处理消息；它甚至不必等待消息系统传递消息。发送方只需要等待消息发送完毕，即消息被消息系统成功存入通道即可。一旦消息被存储，发送者就可以在后台传输消息的同时自由地执行其他工作。

• Asyn­chron­ous com­mu­nic­a­tion. Mes­saging en­ables a send-and-forget ap­proach to com­mu­nic­a­tion. The sender does not have to wait for the re­ceiver to re­ceive and pro­cess the mes­sage; it does not even have to wait for the mes­saging system to de­liver the mes­sage. The sender only needs to wait for the mes­sage to be sent, that is, for the mes­sage to be suc­cess­fully stored in the chan­nel by the mes­saging system. Once the mes­sage is stored, the sender is free to per­form other work while the mes­sage is trans­mit­ted in the back­ground.

• 可变时序。对于同步通信，调用者必须等待接收者完成对调用的处理，然后调用者才能收到结果并继续。这样，呼叫者拨打电话的速度只能与接收者执行呼叫的速度一样快。异步通信允许发送者按照自己的节奏向接收者提交请求，并且接收者按照自己的不同节奏消费请求。这允许两个应用程序以最大吞吐量运行，并且不会浪费时间等待彼此（至少直到接收者用完要处理的消息为止）。

• Vari­able timing. With syn­chron­ous com­mu­nic­a­tion, the caller must wait for the re­ceiver to finish pro­cess­ing the call before the caller can re­ceive the result and con­tinue. In this way, the caller can make calls only as fast as the re­ceiver can per­form them. Asyn­chron­ous com­mu­nic­a­tion allows the sender to submit re­quests to the re­ceiver at its own pace and the re­ceiver to con­sume the re­quests at its own dif­fer­ent pace. This allows both ap­plic­a­tions to run at max­imum through­put and not waste time wait­ing on each other (at least until the re­ceiver runs out of mes­sages to pro­cess).

• 节流。远程过程调用 (RPC) 的一个问题是，单个接收器上同时调用太多远程过程调用可能会使接收器过载。这可能会导致性能下降，甚至导致接收器崩溃。由于消息传递系统会对请求进行排队，直到接收者准备好处理它们，因此接收者可以控制其消耗请求的速率，以免因太多同时请求而导致过载。调用者不受此限制的影响，因为通信是异步的，因此调用者不会因等待接收者而被阻止。

• Throt­tling. A prob­lem with remote pro­ced­ure calls (RPCs) is that too many of them on a single re­ceiver at the same time can over­load the re­ceiver. This can cause per­form­ance de­grad­a­tion and even cause the re­ceiver to crash. Be­cause the mes­saging system queues up re­quests until the re­ceiver is ready to pro­cess them, the re­ceiver can con­trol the rate at which it con­sumes re­quests so as not to become over­loaded by too many sim­ul­tan­eous re­quests. The callers are un­af­fected by this throt­tling be­cause the com­mu­nic­a­tion is asyn­chron­ous, so the callers are not blocked wait­ing on the re­ceiver.

• 可靠的通讯。消息传递提供了 RPC 无法提供的可靠传递。消息传递比 RPC 更可靠的原因是消息传递使用存储转发方法来传输消息。数据被打包为消息，消息是原子的、独立的单元。当发送者发送消息时，消息系统存储该消息。然后，它通过将消息转发到接收者的计算机来传递消息，并再次存储该消息。假定将消息存储在发送者的计算机和接收者的计算机上是可靠的。（为了使其更加可靠，消息可以存储到磁盘而不是内存；请参阅保证传递.) 不可靠的是将消息从发送者的计算机转发（移动）到接收者的计算机，因为接收者或网络可能无法正常运行。消息传递系统通过重新发送消息直到成功来克服这个问题。这种自动重试使消息传递系统能够克服网络问题，以便发送者和接收者不必担心这些细节。

• Re­li­able com­mu­nic­a­tion. Mes­saging provides re­li­able de­liv­ery that an RPC cannot. The reason mes­saging is more re­li­able than RPC is that mes­saging uses a store-and-for­ward ap­proach to trans­mit­ting mes­sages. The data is pack­aged as mes­sages, which are atomic, in­de­pend­ent units. When the sender sends a mes­sage, the mes­saging system stores the mes­sage. It then de­liv­ers the mes­sage by for­ward­ing it to the re­ceiver's com­puter, where it is stored again. Stor­ing the mes­sage on the sender's com­puter and the re­ceiver's com­puter is as­sumed to be re­li­able. (To make it even more re­li­able, the mes­sages can be stored to disk in­stead of memory; see Guar­an­teed De­liv­ery.) What is un­re­li­able is for­ward­ing (moving) the mes­sage from the sender's com­puter to the re­ceiver's com­puter, be­cause the re­ceiver or the net­work may not be run­ning prop­erly. The mes­saging system over­comes this by re­send­ing the mes­sage until it suc­ceeds. This auto­matic retry en­ables the mes­saging system to over­come prob­lems with the net­work so that the sender and re­ceiver don't have to worry about these de­tails.

• 断线操作。某些应用程序专门设计为在与网络断开连接的情况下运行，但在网络连接可用时仍与服务器同步。此类应用程序部署在笔记本电脑和 PDA 等平台上。消息传递非常适合使这些应用程序能够同步，要同步的数据可以在创建时排队，等待应用程序重新连接到网络。

• Dis­con­nec­ted op­er­a­tion. Some ap­plic­a­tions are spe­cific­ally de­signed to run dis­con­nec­ted from the net­work, yet to syn­chron­ize with serv­ers when a net­work con­nec­tion is avail­able. Such ap­plic­a­tions are de­ployed on plat­forms like laptop com­puters and PDAs. Mes­saging is ideal for en­abling these ap­plic­a­tions to syn­chron­izedata to be syn­chron­ized can be queued as it is cre­ated, wait­ing until the ap­plic­a­tion re­con­nects to the net­work.

• 调解。消息传递系统充当中介者模式[GoF ] 中所有可以发送和接收消息的程序之间的中介者。应用程序可以将其用作可集成的其他应用程序或服务的目录。如果某个应用程序与其他应用程序断开连接，它只需重新连接到消息传递系统，而不需要重新连接到所有其他消息传递应用程序。消息传递系统可以利用冗余资源来提供高可用性、平衡负载、重新路由失败的网络连接以及调整性能和服务质量。

• Me­di­ation. The mes­saging system acts as a me­di­at­oras in the Me­di­ator pat­tern [GoF]between all of the pro­grams that can send and re­ceive mes­sages. An ap­plic­a­tion can use it as a dir­ect­ory of other ap­plic­a­tions or ser­vices avail­able to in­teg­rate with. If an ap­plic­a­tion be­comes dis­con­nec­ted from the others, it need only re­con­nect to the mes­saging system, not to all of the other mes­saging ap­plic­a­tions. The mes­saging system can employ re­dund­ant re­sources to provide high avail­ab­il­ity, bal­ance load, reroute around failed net­work con­nec­tions, and tune per­form­ance and qual­ity of ser­vice.

• 线程管理。异步通信意味着一个应用程序在等待另一应用程序执行任务时不必阻塞，除非它愿意。调用者可以使用回调来在回复到达时提醒调用者，而不是阻塞等待回复。（参见请求-回复模式。）大量被阻止的线程或长时间被阻止的线程可能会使应用程序的可用线程太少而无法执行实际工作。此外，如果具有动态数量的阻塞线程的应用程序崩溃，那么当应用程序重新启动并恢复其先前状态时，重新建立这些线程将很困难。对于回调，唯一阻塞的线程是一小部分已知数量的等待回复的侦听器。这使得大多数线程可用于其他工作，并定义了已知数量的侦听器线程，这些线程可以在崩溃后轻松重新建立。

• Thread man­age­ment. Asyn­chron­ous com­mu­nic­a­tion means that one ap­plic­a­tion does not have to block while wait­ing for an­other ap­plic­a­tion to per­form a task, unless it wants to. Rather than block­ing to wait for a reply, the caller can use a call­back that will alert the caller when the reply ar­rives. (See the Re­quest-Reply pat­tern.) A large number of blocked threads or threads blocked for a long time can leave the ap­plic­a­tion with too few avail­able threads to per­form real work. Also, if an ap­plic­a­tion with a dy­namic number of blocked threads crashes, rees­tab­lish­ing those threads will be dif­fi­cult when the ap­plic­a­tion re­starts and re­cov­ers its former state. With call­backs, the only threads that block are a small, known number of listen­ers wait­ing for replies. This leaves most threads avail­able for other work and defines a known number of listener threads that can easily be rees­tab­lished after a crash.

因此，应用程序或企业可以从消息传递中受益的原因有很多。其中一些是应用程序开发人员最容易涉及的技术细节，而另一些则是最能与企业架构师产生共鸣的战略决策。这些原因中哪一个最重要取决于您特定应用程序的当前要求。它们都是使用消息传递的好理由，因此请充分利用可为您带来最大好处的理由。

So, there are a number of dif­fer­ent reas­ons an ap­plic­a­tion or en­ter­prise may be­ne­fit from mes­saging. Some of these are tech­nical de­tails that ap­plic­a­tion de­ve­lopers relate most read­ily to, whereas others are stra­tegic de­cisions that res­on­ate best with en­ter­prise ar­chi­tects. Which of these reas­ons is most im­port­ant de­pends on the cur­rent re­quire­ments of your par­tic­u­lar ap­plic­a­tions. They're all good reas­ons to use mes­saging, so take ad­vant­age of whichever reas­ons provide the most be­ne­fit to you.

异步消息传递的挑战

Challenges of Asynchronous Messaging

异步消息传递并不是集成的万能药。它解决了以优雅的方式集成不同系统的许多挑战，但它也带来了新的挑战。其中一些挑战是异步模型固有的，而其他挑战则因消息传递系统的具体实现而异。

Asyn­chron­ous mes­saging is not the pan­acea of in­teg­ra­tion. It re­solves many of the chal­lenges of in­teg­rat­ing dis­par­ate sys­tems in an el­eg­ant way, but it also in­tro­duces new chal­lenges. Some of these chal­lenges are in­her­ent in the asyn­chron­ous model, while other chal­lenges vary with the spe­cific im­ple­ment­a­tion of a mes­saging system.

• 复杂的编程模型。异步消息传递要求开发人员使用事件驱动的编程模型。应用程序逻辑不再可以在调用其他方法的单个方法中进行编码，而是现在将逻辑分为多个响应传入消息的事件处理程序。这样的系统更加复杂，更难开发和调试。例如，简单方法调用的等价物可能需要请求消息和请求通道、回复消息和回复通道、相关标识符和无效消息队列（如请求-回复中所述）。

• Com­plex pro­gram­ming model. Asyn­chron­ous mes­saging re­quires de­ve­lopers to work with an event-driven pro­gram­ming model. Ap­plic­a­tion logic can no longer be coded in a single method that in­vokes other meth­ods, but in­stead the logic is now split up into a number of event hand­lers that re­spond to in­com­ing mes­sages. Such a system is more com­plex and harder to de­velop and debug. For ex­ample, the equi­val­ent of a simple method call can re­quire a re­quest mes­sage and a re­quest chan­nel, a reply mes­sage and a reply chan­nel, a cor­rel­a­tion iden­ti­fier and an in­valid mes­sage queue (as de­scribed in Re­quest-Reply).

• 顺序问题。消息通道保证消息传递，但不保证消息何时传递。这可能会导致按顺序发送的消息乱序。在消息相互依赖的情况下，必须特别注意重新建立消息序列（请参阅Resequencer ）。

• Se­quence issues. Mes­sage chan­nels guar­an­tee mes­sage de­liv­ery, but they do not guar­an­tee when the mes­sage will be de­livered. This can cause mes­sages that are sent in se­quence to get out of se­quence. In situ­ations where mes­sages depend on each other, spe­cial care has to be taken to rees­tab­lish the mes­sage se­quence (see Resequen­cer).

• 同步场景。并非所有应用程序都可以在“发送后不管”模式下运行。如果用户正在寻找机票，他或她会希望立即查看机票价格，而不是在某个不确定的时间之后查看。因此，许多消息系统需要弥合同步和异步解决方案之间的差距。

• Syn­chron­ous scen­arios. Not all ap­plic­a­tions can op­er­ate in a send-and-forget mode. If a user is look­ing for air­line tick­ets, he or she is going to want to see the ticket price right away, not after some un­deter­mined time. There­fore, many mes­saging sys­tems need to bridge the gap between syn­chron­ous and asyn­chron­ous solu­tions.

• 性能。消息系统确实增加了一些通信开销。将应用程序数据打包成消息并发送，以及接收消息并处理它都需要花费精力。如果您必须传输大量数据，将其分成无数小块可能不是一个明智的主意。例如，如果集成解决方案需要在两个现有系统之间同步信息，第一步通常是将所有相关信息从一个系统复制到另一个系统。对于这样的批量数据复制步骤，ETL（提取、转换和加载）工具比消息传递更有效。消息传递最适合在初始数据复制后保持系统同步。

• Per­form­ance. Mes­saging sys­tems do add some over­head to com­mu­nic­a­tion. It takes effort to pack­age ap­plic­a­tion data into a mes­sage and send it, and to re­ceive a mes­sage and pro­cess it. If you have to trans­port a huge chunk of data, di­vid­ing it into a gazil­lion small pieces may not be a smart idea. For ex­ample, if an in­teg­ra­tion solu­tion needs to syn­chron­ize in­form­a­tion between two ex­ist­ing sys­tems, the first step is usu­ally to rep­lic­ate all rel­ev­ant in­form­a­tion from one system to the other. For such a bulk data rep­lic­a­tion step, ETL (ex­tract, trans­form, and load) tools are much more ef­fi­cient than mes­saging. Mes­saging is best suited to keep­ing the sys­tems in sync after the ini­tial data rep­lic­a­tion.

• 平台支持有限。许多专有消息传递系统并非在所有平台上都可用。通常，通过 FTP 传输文件是唯一的集成选项，因为目标平台可能不支持消息传递系统。

• Lim­ited plat­form sup­port. Many pro­pri­et­ary mes­saging sys­tems are not avail­able on all plat­forms. Often, trans­fer­ring a file via FTP is the only in­teg­ra­tion option be­cause the target plat­form may not sup­port a mes­saging system.

• 供应商锁定。许多消息传递系统的实现都依赖于专有协议。即使是常见的消息传递规范（例如 JMS）也无法控制解决方案的物理实现。因此，不同的消息传递系统通常不会相互连接。这可能会给您带来全新的集成挑战：集成多个集成解决方案！（请参阅消息传递桥模式。）

• Vendor lock-in. Many mes­saging system im­ple­ment­a­tions rely on pro­pri­et­ary pro­to­cols. Even common mes­saging spe­cific­a­tions such as JMS do not con­trol the phys­ical im­ple­ment­a­tion of the solu­tion. As a result, dif­fer­ent mes­saging sys­tems usu­ally do not con­nect to one an­other. This can leave you with a whole new in­teg­ra­tion chal­lenge: in­teg­rat­ing mul­tiple in­teg­ra­tion solu­tions! (See the Mes­saging Bridge pat­tern.)

总之，异步消息传递并不能解决所有问题，甚至可能会产生新的问题。在决定使用消息传递解决哪些问题时，请记住这些后果。

In sum­mary, asyn­chron­ous mes­saging does not solve all prob­lems, and it can even create new ones. Keep these con­se­quences in mind when de­cid­ing which prob­lems to solve using mes­saging.

异步思考

Thinking Asynchronously

消息传递是一种异步技术，可以重试传递直至成功。相反，大多数应用程序使用同步函数调用，例如，一个过程调用子过程、一个方法调用另一个方法，或者一个过程通过 RPC（例如 CORBA 和 DCOM）远程调用另一个过程。同步调用意味着调用进程在子进程执行函数时停止。即使在 RPC 场景中，被调用的子过程在不同的进程中执行，调用者也会阻塞，直到子过程将控制（和结果）返回给调用者。相反，当使用异步消息传递时，调用者使用发送后忽略的方法，允许它在发送消息后继续执行。因此，

Mes­saging is an asyn­chron­ous tech­no­logy, which en­ables de­liv­ery to be re­tried until it suc­ceeds. In con­trast, most ap­plic­a­tions use syn­chron­ous func­tion call­s­for ex­ample, a pro­ced­ure call­ing a sub­pro­ced­ure, one method call­ing an­other method, or one pro­ced­ure in­vok­ing an­other re­motely through an RPC (such as CORBA and DCOM). Syn­chron­ous calls imply that the call­ing pro­cess is halted while the sub­pro­cess is ex­ecut­ing a func­tion. Even in an RPC scen­ario, where the called sub­pro­ced­ure ex­ecutes in a dif­fer­ent pro­cess, the caller blocks until the sub­pro­ced­ure re­turns con­trol (and the res­ults) to the caller. In con­trast, when using asyn­chron­ous mes­saging, the caller uses a send-and-forget ap­proach that allows it to con­tinue to ex­ecute after it sends the mes­sage. As a result, the call­ing pro­ced­ure con­tin­ues to run while the sub­pro­ced­ure is being in­voked (see figure).

同步和异步调用语义

Syn­chron­ous and Asyn­chron­ous Call Se­mantics

异步通信有很多含义。首先，我们不再有单个执行线程。多个线程使子过程能够并发运行，这可以极大地提高性能，并有助于确保某些子进程正在取得进展，即使其他子进程可能正在等待外部结果。然而，并发线程也使调试变得更加困难。其次，结果（如果有）通过回调机制到达。这使得调用者能够执行其他任务，并在结果可用时收到通知，从而提高性能。然而，这意味着调用者即使在其他任务中间也必须能够处理结果，并且必须能够记住进行调用的上下文。第三，异步子流程可以按任何顺序执行。同样，这使得一个子过程能够取得进展，即使另一个子过程不能取得进展。但这也意味着子流程必须能够以任何顺序独立运行，并且调用者必须能够确定哪个结果来自哪个子流程并将结果组合在一起。因此，异步通信具有多个优点，但需要重新考虑过程如何使用其子过程。

Asyn­chron­ous com­mu­nic­a­tion has a number of im­plic­a­tions. First, we no longer have a single thread of ex­e­cu­tion. Mul­tiple threads enable sub­pro­ced­ures to run con­cur­rently, which can greatly im­prove per­form­ance and help ensure that some sub­pro­cesses are making pro­gress even while other sub­pro­cesses may be wait­ing for ex­ternal res­ults. How­ever, con­cur­rent threads also make de­bug­ging much more dif­fi­cult. Second, res­ults (if any) arrive via a call­back mech­an­ism. This en­ables the caller to per­form other tasks and be no­ti­fied when the result is avail­able, which can im­prove per­form­ance. How­ever, this means that the caller has to be able to pro­cess the result even while it is in the middle of other tasks, and it has to be able to re­mem­ber the con­text in which the call was made. Third, asyn­chron­ous sub­pro­cesses can ex­ecute in any order. Again, this en­ables one sub­pro­ced­ure to make pro­gress even while an­other cannot. But it also means that the sub-pro­cesses must be able to run in­de­pend­ently in any order, and the caller must be able to de­term­ine which result came from which sub­pro­cess and com­bine the res­ults to­gether. As a result, asyn­chron­ous com­mu­nic­a­tion has sev­eral ad­vant­ages but re­quires re­think­ing how a pro­ced­ure uses its sub­pro­ced­ures.

分布式应用程序与集成

Distributed Applications versus Integration

本书讲述的是企业集成如何集成独立的应用程序，以便它们可以协同工作。企业应用程序通常采用n层架构（客户端/服务器架构的更复杂版本），使其能够分布在多台计算机上。尽管这会导致不同机器上的进程相互通信，但这只是应用程序分发，而不是应用程序集成。

This book is about en­ter­prise in­teg­ra­tion­how to in­teg­rate in­de­pend­ent ap­plic­a­tions so that they can work to­gether. An en­ter­prise ap­plic­a­tion often in­cor­por­ates an n-tier ar­chi­tec­ture (a more soph­ist­ic­ated ver­sion of a client/server ar­chi­tec­ture), en­abling it to be dis­trib­uted across sev­eral com­puters. Even though this res­ults in pro­cesses on dif­fer­ent ma­chines com­mu­nic­at­ing with each other, this is ap­plic­a­tion dis­tri­bu­tion, not ap­plic­a­tion in­teg­ra­tion.

为什么n层架构被认为是应用程序分发而不是应用程序集成？首先，通信部分紧密耦合，它们直接相互依赖，因此一层无法在没有其他层的情况下运行。其次，层之间的通信趋于同步。第三，应用程序（n层或原子）往往具有只接受快速系统响应时间的人类用户。

Why is an n-tier ar­chi­tec­ture con­sidered ap­plic­a­tion dis­tri­bu­tion and not ap­plic­a­tion in­teg­ra­tion? First, the com­mu­nic­at­ing parts are tightly coupledthey de­pend­ent dir­ectly on each other, so one tier cannot func­tion without the others. Second, com­mu­nic­a­tion between tiers tends to be syn­chron­ous. Third, an ap­plic­a­tion (n-tier or atomic) tends to have human users who will only accept rapid system re­sponse times.

相比之下，集成应用程序是独立的应用程序，每个应用程序都可以自行运行，但以松散耦合的方式相互协调。这使得每个应用程序能够专注于一组全面的功能，同时将相关功能委托给其他应用程序。异步通信的集成应用程序不必等待响应；他们可以在没有响应的情况下继续进行，也可以同时执行其他任务，直到有响应为止。集成应用程序往往具有广泛的时间限制，因此它们可以处理其他任务，直到获得结果，因此比大多数实时等待结果的人类用户更有耐心。

In con­trast, in­teg­rated ap­plic­a­tions are in­de­pend­ent ap­plic­a­tions that can each run by them­selves but that co­ordin­ate with each other in a loosely coupled way. This en­ables each ap­plic­a­tion to focus on one com­pre­hens­ive set of func­tion­al­ity and yet del­eg­ate to other ap­plic­a­tions for re­lated func­tion­al­ity. In­teg­rated ap­plic­a­tions com­mu­nic­at­ing asyn­chron­ously don't have to wait for a re­sponse; they can pro­ceed without a re­sponse or per­form other tasks con­cur­rently until the re­sponse is avail­able. In­teg­rated ap­plic­a­tions tend to have a broad time con­straint, such that they can work on other tasks until a result be­comes avail­able, and there­fore are more pa­tient than most human users wait­ing real-time for a result.

商业消息系统

Commercial Messaging Systems

使用异步消息传递解决方案集成系统的明显好处为创建消息传递中间件和相关工具的软件供应商开辟了一个重要的市场。我们可以将消息厂商的产品大致分为以下四类：

The ap­par­ent be­ne­fits of in­teg­rat­ing sys­tems using an asyn­chron­ous mes­saging solu­tion have opened up a sig­ni­fic­ant market for soft­ware vendors cre­at­ing mes­saging mid­dle­ware and as­so­ci­ated tools. We can roughly group the mes­saging vendors' products into the fol­low­ing four cat­egor­ies:

本书中的模式与供应商无关，适用于大多数消息传递解决方案。不幸的是，每个供应商在描述消息传递解决方案时都倾向于定义自己的术语。在本书中，我们努力选择技术和产品中立但具有描述性且易于对话使用的模式名称。

The pat­terns in this book are vendor-in­de­pend­ent and apply to most mes­saging solu­tions. Un­for­tu­nately, each vendor tends to define its own ter­min­o­logy when de­scrib­ing mes­saging solu­tions. In this book, we strove to choose pat­tern names that are tech­no­logy- and product-neut­ral yet de­script­ive and easy to use con­ver­sa­tion­ally.

许多消息传递供应商已将本书的一些模式作为其产品的功能，这简化了模式的应用并加速了解决方案的开发。熟悉特定供应商术语的读者很可能会认识本书中的许多概念。为了帮助这些读者将模式语言映射到供应商特定的术语，下表将最常见的模式名称映射到一些最广泛使用的消息传递产品中相应的产品功能名称。

Many mes­saging vendors have in­cor­por­ated some of this book's pat­terns as fea­tures of their products, which sim­pli­fies ap­ply­ing the pat­terns and ac­cel­er­ates solu­tion de­vel­op­ment. Read­ers who are fa­mil­iar with a par­tic­u­lar vendor's ter­min­o­logy will most likely re­cog­nize many of the con­cepts in this book. To help these read­ers map the pat­tern lan­guage to the vendor-spe­cific ter­min­o­logy, the fol­low­ing tables map the most common pat­tern names to their cor­res­pond­ing product fea­ture names in some of the most widely used mes­saging products.

图案形式

Pattern Form

本书包含一组组织成模式语言的模式。《设计模式》、《面向模式J2EE的模式》和《企业应用程序架构模式》等书籍已经普及了使用模式来记录计算机编程技术的概念。Christopher Alexander 在他的著作《A Pattern Language》和《A Timeless Way of Building》中开创了模式和模式语言的概念。每个模式都代表一个必须做出的决定以及该决定中的考虑因素。模式语言是一个由相关模式组成的网络，其中每个模式都引向其他模式，从而指导您完成决策过程。这种方法是一种强大的技术，可以记录专家的知识，以便其他人可以轻松理解和应用。

This book con­tains a set of pat­terns or­gan­ized into a pat­tern lan­guage. Books such as Design Pat­terns, Pat­tern Ori­ented Soft­ware Ar­chi­tec­ture, Core J2EE Pat­terns, and Pat­terns of En­ter­prise Ap­plic­a­tion Ar­chi­tec­ture have pop­ular­ized the concept of using pat­terns to doc­u­ment com­puter-pro­gram­ming tech­niques. Chris­topher Al­ex­an­der pi­on­eered the concept of pat­terns and pat­tern lan­guages in his books A Pat­tern Lan­guage and A Time­less Way of Build­ing. Each pat­tern rep­res­ents a de­cision that must be made and the con­sid­er­a­tions that go into that de­cision. A pat­tern lan­guage is a web of re­lated pat­terns where each pat­tern leads to others, guid­ing you through the de­cision-making pro­cess. This ap­proach is a power­ful tech­nique for doc­u­ment­ing an expert's know­ledge so that it can be read­ily un­der­stood and ap­plied by others.

模式语言教您如何在有限的问题空间内解决无限种问题。由于每次要解决的总体问题都不同，因此模式的路径及其应用方式也是独特的。本书是为任何在任何应用程序中使用任何消息传递工具的人编写的，它可以专门针对您以及您所面临的独特的消息传递应用程序。

A pat­tern lan­guage teaches you how to solve a lim­it­less vari­ety of prob­lems within a bounded prob­lem space. Be­cause the over­all prob­lem that is being solved is dif­fer­ent every time, the path through the pat­terns and how they're ap­plied is also unique. This book is writ­ten for anyone using any mes­saging tools for any ap­plic­a­tion, and it can be ap­plied spe­cific­ally for you and the unique ap­plic­a­tion of mes­saging that you face.

单独使用模式形式并不能保证一本书包含丰富的知识。仅仅说“当你遇到这个问题时，应用这个解决方案”是不够的。为了让您真正从模式中学习，该模式必须记录为什么问题难以解决，考虑实际上效果不佳的可能解决方案，并解释为什么所提供的解决方案是最好的解决方案。同样，这些模式需要相互连接，以便引导您从一个问题到下一个问题。通过这种方式，模式形式不仅可以用来教导应用什么解决方案，还可以用来教导如何解决作者无法预测的问题。这些是我们在本书中努力实现的目标。

Using the pat­tern form by itself does not guar­an­tee that a book con­tains a wealth of know­ledge. It is not enough to simply say, "When you face this prob­lem, apply this solu­tion." For you to truly learn from a pat­tern, the pat­tern has to doc­u­ment why the prob­lem is dif­fi­cult to solve, con­sider pos­sible solu­tions that in fact don't work well, and ex­plain why the solu­tion offered is the best avail­able. Like­wise, the pat­terns need to con­nect to each other so as to walk you from one prob­lem to the next. In this way, the pat­tern form can be used to teach not just what solu­tions to apply but also how to solve prob­lems the au­thors could not have pre­dicted. These are goals we strive to ac­com­plish in this book.

模式应该是规范性的，这意味着它们应该告诉您要做什么。它们不只是描述问题，也不只是描述如何解决问题，而是告诉您如何解决问题。每个模式代表您必须做出的决定：“我应该使用消息传递吗？ ” “命令信息对我有帮助吗？” 模式和模式语言的目的是帮助您做出决策，从而为您的特定问题提供良好的解决方案，即使作者没有考虑到该特定问题，即使您没有知识和经验自己开发该解决方案的经验。

Pat­terns should be pre­script­ive, mean­ing that they should tell you what to do. They don't just de­scribe a prob­lem, and they don't just de­scribe how to solve itthey tell you what to do to solve it. Each pat­tern rep­res­ents a de­cision you must make: "Should I use Mes­saging?" "Would a Com­mand Mes­sage help me here?" The point of the pat­terns and the pat­tern lan­guage is to help you make de­cisions that lead to a good solu­tion for your spe­cific prob­lem, even if the au­thors didn't have that spe­cific prob­lem in mind and even if you don't have the know­ledge and ex­per­i­ence to de­velop that solu­tion on your own.

没有一种通用的模式形式；不同的书使用不同的结构。我们使用了一种与亚历山大形式相当接近的风格，这种风格首先在Kent Beck的《Smalltalk 最佳实践模式》中在计算机编程中得到普及。我们喜欢亚历山大形式，因为它产生的模式更像散文。因此，尽管每个模式都遵循相同的、定义明确的结构，但该格式避免了各个小节的标题，这会破坏讨论的流程。为了提高导航性，该格式使用下划线、缩进和插图等样式元素来帮助您快速识别重要信息。

There is no one uni­ver­sal pat­tern form; dif­fer­ent books use vari­ous struc­tures. We used a style that is fairly close to the Al­ex­an­drian form, which was first pop­ular­ized for com­puter pro­gram­ming in Small­talk Best Prac­tice Pat­terns by Kent Beck. We like the Al­ex­an­drian form be­cause it res­ults in pat­terns that are more prose-like. As a result, even though each pat­tern fol­lows an identical, well-defined struc­ture, the format avoids head­ings for in­di­vidual sub­sec­tions, which would dis­rupt the flow of the dis­cus­sion. To im­prove nav­ig­ab­il­ity, the format uses style ele­ments such as un­der­scor­ing, in­dent­a­tion, and il­lus­tra­tions to help you identify im­port­ant in­form­a­tion at a quick glance.

每个模式都遵循以下结构：

Each pat­tern fol­lows this struc­ture:

• 名称 这是模式的标识符，指示模式的用途。我们选择了易于在句子中使用的名称，以便在设计师之间的对话中轻松引用模式的概念。

• Name This is an iden­ti­fier for the pat­tern that in­dic­ates what the pat­tern does. We chose names that can easily be used in a sen­tence so that it is easy to ref­er­ence the pat­tern's concept in a con­ver­sa­tion between de­sign­ers.

• 图标 除了模式名称之外，大多数模式还与图标相关联。由于许多建筑师习惯于通过图表进行视觉交流，因此除了口头语言之外，我们还提供视觉语言。这种视觉语言强调了模式的可组合性，因为可以组合多个模式图标来描述更大、更复杂模式的解决方案。

• Icon Most pat­terns are as­so­ci­ated with an icon in ad­di­tion to the pat­tern name. Be­cause many ar­chi­tects are used to com­mu­nic­at­ing visu­ally through dia­grams, we provide a visual lan­guage in ad­di­tion to the verbal lan­guage. This visual lan­guage un­der­lines the com­pos­ab­il­ity of the pat­terns, as mul­tiple pat­tern icons can be com­bined to de­scribe the solu­tion of a larger, more com­plex pat­tern.

• 上下文 本节解释什么类型的工作可能会让您遇到此模式解决的问题。上下文为问题奠定了基础，并且通常指的是您可能已经应用的其他模式。

• Con­text This sec­tion ex­plains what type of work might make you run into the prob­lem that this pat­tern solves. The con­text sets the stage for the prob­lem and often refers to other pat­terns you may have already ap­plied.

• 问题 这解释了您所面临的困难，以问题的形式表达。您应该能够阅读问题陈述并快速确定该模式是否与您的工作相关。我们已将问题格式化为由水平规则分隔的一个句子。

• Prob­lem This ex­plains the dif­fi­culty you are facing, ex­pressed as a ques­tion. You should be able to read the prob­lem state­ment and quickly de­term­ine if this pat­tern is rel­ev­ant to your work. We've format­ted the prob­lem to be one sen­tence de­lim­ited by ho­ri­zontal rules.

• 力量 力量探索使问题难以解决的限制因素。他们经常考虑看似有前途但效果不佳的替代解决方案，这有助于展示真正解决方案的价值。

• Forces The forces ex­plore the con­straints that make the prob­lem dif­fi­cult to solve. They often con­sider al­tern­at­ive solu­tions that seem prom­ising but don't pan out, which helps show the value of the real solu­tion.

• 解决方案 本部分说明您应该采取哪些措施来解决该问题。它不限于您的特定情况，而是描述了在问题所代表的各种情况下该怎么做。如果您了解模式的问题和解决方案，您就了解了该模式。我们采用与问题相同的风格来格式化解决方案，以便您在阅读本书时可以轻松发现问题和解决方案的陈述。

• Solu­tion This part ex­plains what you should do to solve the prob­lem. It is not lim­ited to your par­tic­u­lar situ­ation, but de­scribes what to do in the vari­ety of cir­cum­stances rep­res­en­ted by the prob­lem. If you un­der­stand a pat­tern's prob­lem and solu­tion, you un­der­stand the pat­tern. We've format­ted the solu­tion in the same style as the prob­lem so that you can easily spot prob­lem and solu­tion state­ments when per­us­ing the book.

• 草图 亚历山大形式最吸引人的特性之一是每个模式都包含一个说明解决方案的草图。很多时候，只要看图案名称和草图，就可以了解图案的本质。我们试图通过紧跟每个模式的解决方案陈述之后用图来说明解决方案来保持这种风格。

• Sketch One of the most ap­peal­ing prop­er­ties of the Al­ex­an­drian form is that each pat­tern con­tains a sketch that il­lus­trates the solu­tion. In many cases, just by look­ing at the pat­tern name and the sketch, you can un­der­stand the es­sence of the pat­tern. We tried to main­tain this style by il­lus­trat­ing the solu­tion with a figure im­me­di­ately fol­low­ing the solu­tion state­ment of each pat­tern.

• 结果 这部分对解决方案进行了扩展，以解释如何应用该解决方案以及如何解决力的详细信息。它还解决了应用此模式可能出现的新挑战。

• Res­ults This part ex­pands upon the solu­tion to ex­plain the de­tails of how to apply the solu­tion and how it re­solves the forces. It also ad­dresses new chal­lenges that may arise as a result of ap­ply­ing this pat­tern.

• 下一步 本节列出了应用当前模式后要考虑的其他模式。模式并不是孤立存在的；一种模式的应用通常会导致您遇到其他模式可以解决的新问题。模式之间的关系构成了模式语言，而不仅仅是模式目录。

• Next This sec­tion lists other pat­terns to be con­sidered after ap­ply­ing the cur­rent one. Pat­terns don't live in isol­a­tion; the ap­plic­a­tion of one pat­tern usu­ally leads you to new prob­lems that are solved by other pat­terns. The re­la­tion­ships between pat­terns are what con­sti­tutes a pat­tern lan­guage as op­posed to just a pat­tern cata­log.

• 侧边栏 这些部分讨论更详细的技术问题或模式的变体。我们将这些部分在视觉上与文本的其余部分分开，因此如果它们与您的模式的特定应用不相关，您可以轻松地跳过它们。

• Side­bars These sec­tions dis­cuss more de­tailed tech­nical issues or vari­ations of the pat­tern. We set these sec­tions visu­ally apart from the re­mainder of the text so you can easily skip them if they are not rel­ev­ant to your par­tic­u­lar ap­plic­a­tion of the pat­tern.

• 示例 图案通常包括正在应用或已经应用的图案的一个或多个示例。示例可以像命名已知用途一样简单，也可以像一大段示例代码一样详细。鉴于可用的消息传递技术有大量，我们不希望您熟悉用于实现示例的每种技术。因此，我们设计了这些模式，以便您可以安全地跳过该示例，而不会丢失该模式的任何关键内容。

• Ex­amples A pat­tern usu­ally in­cludes one or more ex­amples of the pat­tern being ap­plied or having been ap­plied. An ex­ample may be as simple as naming a known use or as de­tailed as a large seg­ment of sample code. Given the large number of avail­able mes­saging tech­no­lo­gies, we do not expect you to be fa­mil­iar with each tech­no­logy used to im­ple­ment an ex­ample. There­fore, we de­signed the pat­terns so that you can safely skip the ex­ample without losing any crit­ical con­tent of the pat­tern.

将解决方案描述为模式的美妙之处在于，它不仅教您如何解决所讨论的具体问题，还教您如何创建解决作者甚至没有意识到的问题的设计。因此，这些消息传递模式不仅描述了当今存在的消息传递系统，而且还可能适用于本书出版后创建的新系统。

The beauty in de­scrib­ing solu­tions as pat­terns is that it teaches you not only how to solve the spe­cific prob­lems dis­cussed, but also how to create designs that solve prob­lems the au­thors were not even aware of. As a result, these pat­terns for mes­saging not only de­scribe mes­saging sys­tems that exist today, but may also apply to new ones cre­ated well after this book is pub­lished.

图表符号

Diagram Notation

集成解决方案由许多不同的部分组成：应用程序、数据库、端点、通道、消息、路由器等。如果我们想要描述一个集成解决方案，我们需要定义一个能够容纳所有这些不同组件的符号。据我们所知，还没有一种广泛使用的、全面的符号可以用来描述集成解决方案的各个方面。统一建模语言 (UML) 在使用类图和交互图描述面向对象的系统方面做得很好，但它不包含描述消息传递解决方案的语义。EAI 的 UML 概要文件 [ UMLEAI] 丰富了协作图的语义来描述组件之间的消息流。这种表示法作为精确的可视化规范非常有用，可以作为模型驱动架构 (MDA) 一部分的代码生成的基础。我们决定不采用这种表示法有两个原因。首先，UML Profile 并没有捕获我们的模式语言中描述的所有模式。其次，我们并不是要创建精确的视觉规范，而是要创建具有一定“草图”质量的图像。我们想要的图片能够一目了然地传达图案的本质，就像亚历山大的草图一样。这就是为什么我们决定创建我们自己的“符号”。幸运的是，与更正式的符号不同，我们的符号不需要您阅读大量手册。一张简单的图片就足够了：

In­teg­ra­tion solu­tions con­sist of many dif­fer­ent pieces­ap­plic­a­tions, data­bases, en­d­points, chan­nels, mes­sages, routers, and so on. If we want to de­scribe an in­teg­ra­tion solu­tion, we need to define a nota­tion that ac­com­mod­ates all these dif­fer­ent com­pon­ents. To our know­ledge, there is no widely used, com­pre­hens­ive nota­tion that is geared toward the de­scrip­tion of all as­pects of an in­teg­ra­tion solu­tion. The Uni­fied Mod­el­ing Lan­guage (UML) does a fine job of de­scrib­ing object-ori­ented sys­tems with class and in­ter­ac­tion dia­grams, but it does not con­tain se­mantics to de­scribe mes­saging solu­tions. The UML Pro­file for EAI [UMLEAI] en­riches the se­mantics of col­lab­or­a­tion dia­grams to de­scribe mes­sage flows between com­pon­ents. This nota­tion is very useful as a pre­cise visual spe­cific­a­tion that can serve as the basis for code gen­er­a­tion as part of a model-driven ar­chi­tec­ture (MDA). We de­cided not to adopt this nota­tion for two reas­ons. First, the UML Pro­file does not cap­ture all the pat­terns de­scribed in our pat­tern lan­guage. Second, we were not look­ing to create a pre­cise visual spe­cific­a­tion, but images that have a cer­tain "sketch" qual­ity to them. We wanted pic­tures that are able to convey the es­sence of a pat­tern at a quick glancevery much like Al­ex­an­der's sketch. That's why we de­cided to create our own "nota­tion." Luck­ily, unlike the more formal nota­tion, ours does not re­quire you to read a large manual. A simple pic­ture should suf­fice:

消息传递解决方案的视觉符号

Visual Nota­tion for Mes­saging Solu­tions

这个简单的图片显示了通过通道发送到组件的消息。我们使用“组件”这个词这里它可以非常宽松地指示正在集成的应用程序、在应用程序之间转换或路由消息的中介或应用程序的特定部分。有时，如果我们想突出通道本身，我们也会将通道描绘为三维管道。通常，我们对组件更感兴趣，并将通道绘制为带箭头的简单线条。这两种表示法是等效的。我们将消息描述为一棵小树，具有圆形根和嵌套的方形元素，因为许多消息传递系统允许消息包含树状数据结构（例如 XML 文档）。树元素可以加阴影或着色以突出它们在特定模式中的用途。

This simple pic­ture shows a mes­sage being sent to a com­pon­ent over a chan­nel. We use the word com­pon­ent very loosely hereit can in­dic­ate an ap­plic­a­tion that is being in­teg­rated, an in­ter­me­di­ary that trans­forms or routes the mes­sage between ap­plic­a­tions, or a spe­cific part of an ap­plic­a­tion. Some­times, we also depict a chan­nel as a three-di­men­sional pipe if we want to high­light the chan­nel itself. Often, we are more in­ter­ested in the com­pon­ents and draw the chan­nels as simple lines with arrow heads. The two nota­tions are equi­val­ent. We depict the mes­sage as a small tree with a round root and nested, square ele­ments be­cause many mes­saging sys­tems allow mes­sages to con­tain tree-like data struc­tures­for ex­ample, XML doc­u­ments. The tree ele­ments can be shaded or colored to high­light their usage in a par­tic­u­lar pat­tern. De­pict­ing mes­sages in this way allows us to provide a quick visual de­scrip­tion of trans­form­a­tion pat­ternsit is easy to show a pat­tern that adds, re­ar­ranges, or re­moves fields from the mes­sage.

当我们描述应用程序设计时，例如，消息传递端点或用 C# 或 Java 编写的示例，我们确实使用标准 UML 类和序列图来描述类层次结构和对象之间的交互，因为 UML 表示法被广泛接受为描述这些类型的标准方式。解决方案（如果您需要复习 UML，请查看 [ UML ]）。

When we de­scribe ap­plic­a­tion designs­for ex­ample, mes­saging en­d­points or ex­amples writ­ten in C# or Javawe do use stand­ard UML class and se­quence dia­grams to depict the class hier­archy and the in­ter­ac­tion between ob­jects be­cause the UML nota­tion is widely ac­cep­ted as the stand­ard way of de­scrib­ing these types of solu­tions (if you need a re­fresher on UML, have a look at [UML]).

示例和插曲

Examples and Interludes

我们试图通过包含使用各种集成技术的实现示例来强调这些模式的广泛适用性。这种方法的潜在缺点是您可能不熟悉示例中使用的每种技术。这就是为什么我们确保阅读示例是严格可选的，所有相关点都在模式描述中讨论。因此，您可以安全地跳过这些示例，而不会丢失重要细节。此外，在可能的情况下，我们提供了多个使用不同技术的实现示例。

We have tried to un­der­line the broad ap­plic­ab­il­ity of the pat­terns by in­clud­ing im­ple­ment­a­tion ex­amples using a vari­ety of in­teg­ra­tion tech­no­lo­gies. The po­ten­tial down­side of this ap­proach is that you may not be fa­mil­iar with each tech­no­logy that is being used in an ex­ample. That's why we made sure that read­ing the ex­amples is strictly op­tion­alall rel­ev­ant points are dis­cussed in the pat­tern de­scrip­tion. There­fore, you can safely skip the ex­amples without risk of losing out on im­port­ant detail. Also, where pos­sible, we provided more than one im­ple­ment­a­tion ex­ample using dif­fer­ent tech­no­lo­gies.

在提供示例代码时，我们关注的是可读性而不是可运行性。代码段可以帮助消除解决方案描述留下的任何潜在歧义，许多应用程序开发人员和架构师更喜欢查看 30 行代码而不是阅读许多文本段落。为了支持这一意图，我们通常只显示潜在更大解决方案中最相关的方法或类。我们还省略了大多数形式的错误检查，以突出代码实现的核心功能。大多数代码片段不包含内嵌注释，因为代码在代码段之前和之后的段落中进行了解释。

When present­ing ex­ample code, we fo­cused on read­ab­il­ity over run­nab­il­ity. A code seg­ment can help remove any po­ten­tial am­bi­gu­ity left by the solu­tion de­scrip­tion, and many ap­plic­a­tion de­ve­lopers and ar­chi­tects prefer look­ing at 30 lines of code to read­ing many para­graphs of text. To sup­port this intent, we often show only the most rel­ev­ant meth­ods or classes of a po­ten­tially larger solu­tion. We also omit­ted most forms of error check­ing to high­light the core func­tion im­ple­men­ted by the code. Most code snip­pets do not con­tain in-line com­ments, as the code is ex­plained in the para­graphs before and after the code seg­ment.

为单一集成模式提供有意义的示例具有挑战性。企业集成解决方案通常由分布在多个系统中的许多异构组件组成。同样，大多数集成模式并不是孤立运行的，而是依赖其他模式来形成有意义的解决方案。为了强调多种模式之间的协作，我们提供了更全面的示例作为插曲（请参阅第 6 章、第 9 章和第12 章）。这些解决方案说明了设计更全面的消息传递解决方案时涉及的许多权衡。

Provid­ing a mean­ing­ful ex­ample for a single in­teg­ra­tion pat­tern is chal­len­ging. En­ter­prise in­teg­ra­tion solu­tions typ­ic­ally con­sist of a number of het­ero­gen­eous com­pon­ents spread across mul­tiple sys­tems. Like­wise, most in­teg­ra­tion pat­terns do not op­er­ate in isol­a­tion but rely on other pat­terns to form a mean­ing­ful solu­tion. To high­light the col­lab­or­a­tion between mul­tiple pat­terns, we in­cluded more com­pre­hens­ive ex­amples as in­ter­ludes (see Chapters 6, 9, and 12). These solu­tions il­lus­trate many of the trade-offs in­volved in design­ing a more com­pre­hens­ive mes­saging solu­tion.

所有代码示例仅应视为说明性工具，而不应作为开发生产质量集成解决方案的起点。例如，几乎所有示例都缺乏任何形式的错误检查或对鲁棒性、安全性或可扩展性的关注。

All code samples should be treated as il­lus­trat­ive tools only and not as a start­ing point for de­vel­op­ment of a pro­duc­tion-qual­ity in­teg­ra­tion solu­tion. For ex­ample, almost all ex­amples lack any form of error check­ing or con­cern for ro­bust­ness, se­cur­ity, or scalab­il­ity.

我们尽可能地将示例基于免费或试用版的软件平台。在某些情况下，我们使用商业平台（例如 TIBCO ActiveEnterprise 和 Microsoft BizTalk）来说明从头开始开发解决方案与使用商业工具之间的区别。我们以这样的方式呈现这些示例，即使您无法访问所需的运行时平台，它们也具有教育意义。对于许多示例，我们使用相对简单的消息传递框架，例如 JMS 或 MSMQ。这使我们能够在示例中更加明确，并专注于手头的问题，而不是使用更复杂的中间件工具集可能提供的所有功能来分散注意力。

We tried as much as pos­sible to base the ex­amples on soft­ware plat­forms that are avail­able free of charge or as a trial ver­sion. In some cases, we used com­mer­cial plat­forms (such as TIBCO Act­iveEn­ter­prise and Mi­crosoft BizTalk) to il­lus­trate the dif­fer­ence between de­vel­op­ing a solu­tion from scratch and using a com­mer­cial tool. We presen­ted those ex­amples in such a way that they are edu­ca­tional even if you do not have access to the re­quired runtime plat­form. For many ex­amples, we use re­l­at­ively bare­bones mes­saging frame­works such as JMS or MSMQ. This allows us to be more ex­pli­cit in the ex­ample and focus on the prob­lem at hand in­stead of dis­tract­ing from it with all the fea­tures a more com­plex mid­dle­ware tool­set may provide.

本书中的Java 示例基于JMS 1.1 规范，该规范是J2EE 1.4 规范的一部分。到本书出版时，大多数消息传递和应用程序服务器供应商都将支持 JMS 1.1。您可以从 Sun 的网站下载 Sun Microsystems 的 JMS 规范参考实现： http: //java.sun.com/j2ee。

The Java ex­amples in this book are based on the JMS 1.1 spe­cific­a­tion, which is part of the J2EE 1.4 spe­cific­a­tion. By the time this book is pub­lished, most mes­saging and ap­plic­a­tion server vendors will sup­port JMS 1.1. You can down­load Sun Mi­crosys­tems' ref­er­ence im­ple­ment­a­tion of the JMS spe­cific­a­tion from Sun's Web site: http://java.sun.com/j2ee.

Microsoft .NET 示例基于 .NET Framework 1.1 版，并用 C# 编写。您可以从 Microsoft 网站下载 .NET Framework SDK：http://msdn.microsoft.com/net。

The Mi­crosoft .NET ex­amples are based on Ver­sion 1.1 of the .NET Frame­work and are writ­ten in C#. You can down­load the .NET Frame­work SDK from Mi­crosoft's Web site: http://msdn.mi­crosoft.com/net.

本书的组织结构

Organization of This Book

本书中的模式语言与任何模式语言一样，是一个相互引用的模式网络。同时，某些模式比其他模式更基本，形成大概念模式的层次结构，从而导致更精细的模式。大概念模式构成了模式语言的承载成员。它们是主要的模式，是提供语言基础并支持其他模式的根模式。

The pat­tern lan­guage in this book, as with any pat­tern lan­guage, is a web of pat­terns re­fer­ring to each other. At the same time, some pat­terns are more fun­da­mental than others, form­ing a hier­archy of big-concept pat­terns that lead to more finely de­tailed pat­terns. The big-concept pat­terns form the load-bear­ing mem­bers of the pat­tern lan­guage. They are the main ones, the root pat­terns that provide the found­a­tion of the lan­guage and sup­port the other pat­terns.

本书按抽象级别和主题领域将模式分为几章。下图显示了根模式及其与本书各章节的关系。

This book groups pat­terns into chapters by level of ab­strac­tion and by topic area. The fol­low­ing dia­gram shows the root pat­terns and their re­la­tion­ship to the chapters of the book.

根模式和章节的关系

Re­la­tion­ship of Root Pat­terns and Chapters

最基本的模式是消息传递；这就是本书的主题。它导致了第 3 章“消息系统”中描述的六种根模式，即消息通道、消息、管道和过滤器、消息路由器、消息转换器和消息端点。反过来，每个根模式都会导致本书中自己的章节（管道和过滤器除外，它们不是特定于消息传递的，而是一种广泛使用的架构风格，构成了路由和转换模式的基础）。

The most fun­da­mental pat­tern is Mes­saging; that's what this book is about. It leads to the six root pat­terns de­scribed in Chapter 3, "Mes­saging Sys­tems," namely, Mes­sage Chan­nel, Mes­sage, Pipes and Fil­ters, Mes­sage Router, Mes­sage Trans­lator, and Mes­sage En­d­point. In turn, each root pat­tern leads to its own chapter in the book (except Pipes and Fil­ters, which is not spe­cific to mes­saging but is a widely used ar­chi­tec­tural style that forms the basis of the rout­ing and trans­form­a­tion pat­terns).

模式语言分为八章，遵循刚刚描述的层次结构：

The pat­tern lan­guage is di­vided into eight chapters, which follow the hier­archy just de­scribed:

第 2 章，“集成样式” 本章回顾了可用于集成应用程序的不同方法，包括消息传递。

第 3 章，“消息传递系统” 本章回顾了六种根消息传递模式，概述了整个模式语言。

第 4 章，“消息传递通道” 应用程序通过通道进行通信。通道定义消息可以遵循的逻辑路径。本章介绍如何确定您的应用程序需要哪些通道。

第 5 章，“消息构造” 一旦有了消息通道，您就需要在它们上发送消息。本章解释了使用消息的不同方式以及如何利用它们的特殊属性。

第 7 章，“消息路由” 消息传递解决方案旨在解耦信息的发送者和接收者。消息路由器提供发送者和接收者之间的位置独立性，以便发送者不必知道谁处理他们的消息。相反，它们将消息发送到中间消息路由组件，中间消息路由组件将消息转发到正确的目的地。本章介绍了各种不同的路由技术。

第 8 章，“消息转换” 独立开发的应用程序通常在消息格式、所谓唯一标识符的形式和含义、甚至要使用的字符编码方面不一致。因此，需要中间组件将消息从一个应用程序生成的格式转换为接收应用程序的格式。本章介绍如何设计变压器组件。

第 10 章，“消息传送端点” 许多应用程序并不是为参与消息传送解决方案而设计的。因此，它们必须显式连接到消息传递系统。本章描述应用程序中负责发送和接收消息的层，使您的应用程序成为消息的端点。

第 11 章，“系统管理” 一旦消息系统准备好集成应用程序，我们如何确保它正确运行并执行我们想要的操作？本章探讨如何测试和监视正在运行的消息系统。

Chapter 2, "In­teg­ra­tion Styles" This chapter re­views the dif­fer­ent ap­proaches avail­able for in­teg­rat­ing ap­plic­a­tions, in­clud­ing Mes­saging.

Chapter 3, "Mes­saging Sys­tems" This chapter re­views the six root mes­saging pat­terns, giving an over­view of the entire pat­tern lan­guage.

Chapter 4, "Mes­saging Chan­nels" Ap­plic­a­tions com­mu­nic­ate via chan­nels. Chan­nels define the lo­gical path­ways a mes­sage can follow. This chapter shows how to de­term­ine what chan­nels your ap­plic­a­tions need.

Chapter 5, "Mes­sage Con­struc­tion" Once you have mes­sage chan­nels, you need mes­sages to send on them. This chapter ex­plains the dif­fer­ent ways mes­sages can be used and how to take ad­vant­age of their spe­cial prop­er­ties.

Chapter 7, "Mes­sage Rout­ing" Mes­saging solu­tions aim to de­couple the sender and the re­ceiver of in­form­a­tion. Mes­sage routers provide loc­a­tion in­de­pend­ence between sender and re­ceiver so that senders don't have to know about who pro­cesses their mes­sages. Rather, they send the mes­sages to in­ter­me­di­ate mes­sage rout­ing com­pon­ents that for­ward the mes­sage to the cor­rect des­tin­a­tion. This chapter presents a vari­ety of dif­fer­ent rout­ing tech­niques.

Chapter 8, "Mes­sage Trans­form­a­tion" In­de­pend­ently de­ve­loped ap­plic­a­tions often don't agree on mes­sages' formats, on the form and mean­ing of sup­posedly unique iden­ti­fi­ers, or even on the char­ac­ter en­cod­ing to be used. There­fore, in­ter­me­di­ate com­pon­ents are needed to con­vert mes­sages from the format one ap­plic­a­tion pro­duces to that of the re­ceiv­ing ap­plic­a­tions. This chapter shows how to design trans­former com­pon­ents.

Chapter 10, "Mes­saging En­d­points" Many ap­plic­a­tions were not de­signed to par­ti­cip­ate in a mes­saging solu­tion. As a result, they must be ex­pli­citly con­nec­ted to the mes­saging system. This chapter de­scribes a layer in the ap­plic­a­tion that is re­spons­ible for send­ing and re­ceiv­ing the mes­sages, making your ap­plic­a­tion an en­d­point for mes­sages.

Chapter 11, "System Man­age­ment" Once a mes­saging system is in place to in­teg­rate ap­plic­a­tions, how do we make sure that it's run­ning cor­rectly and doing what we want? This chapter ex­plores how to test and mon­itor a run­ning mes­saging system.

这八章共同教您有关使用消息传递连接应用程序所需了解的知识。

These eight chapters to­gether teach you what you need to know about con­nect­ing ap­plic­a­tions using mes­saging.

入门

Getting Started

对于任何一本有很多东西要教的书，对于作者和读者来说都很难知道从哪里开始。直接阅读所有页面可以确保涵盖整个主题领域，但这并不是解决最有帮助的问题的最快方法。从语言中间的模式开始就像开始看一部看了一半的电影一样，你看到正在发生的事情，但不明白它的含义。

With any book that has a lot to teach, it's hard to know where to start, both for the au­thors and the read­ers. Read­ing all of the pages straight through as­sures cov­er­ing the entire sub­ject area but isn't the quick­est way to get to the issues that are of the most help. Start­ing with a pat­tern in the middle of the lan­guage can be like start­ing to watch a movie that's half overyou see what's hap­pen­ing but don't un­der­stand what it means.

幸运的是，模式语言是围绕前面描述的根模式形成的。这些根模式共同提供了模式语言的概述，并单独提供了深入研究消息传递细节的起点。要在不回顾所有模式的情况下对语言进行全面调查，请从回顾第 3 章中的根模式开始。

Luck­ily, the pat­tern lan­guage is formed around the root pat­terns de­scribed earlier. These root pat­terns col­lect­ively provide an over­view of the pat­tern lan­guage, and in­di­vidu­ally provide start­ing points for delving deep into the de­tails of mes­saging. To get an over­all survey of the lan­guage without re­view­ing all of the pat­terns, start with re­view­ing the root pat­terns in Chapter 3.

第 2 章“集成风格”概述了四种主要的应用程序集成技术，并确定消息传递是许多集成机会的最佳整体方法。如果您不熟悉应用程序集成中涉及的问题以及各种可用方法的优缺点，请阅读本章。如果您已经确信消息传递是正确的选择，并且想要开始了解如何使用消息传递，则可以完全跳过本章。

Chapter 2, "In­teg­ra­tion Styles," provides an over­view of the four main ap­plic­a­tion in­teg­ra­tion tech­niques and settles on Mes­saging as being the best over­all ap­proach for many in­teg­ra­tion op­por­tun­it­ies. Read this chapter if you are un­fa­mil­iar with issues in­volved in ap­plic­a­tion in­teg­ra­tion and the pros and cons of the vari­ous ap­proaches that are avail­able. If you're already con­vinced that mes­saging is the way to go and want to get star­ted with how to use mes­saging, you can skip this chapter com­pletely.

第 3 章“消息传递系统”包含该模式语言的所有根模式（除了第2 章中的消息传递） 。要了解模式语言的概述，请阅读（或至少浏览）本章中的所有模式。要深入研究特定主题，请阅读其根模式，然后转到模式部分末尾提到的模式；接下来的模式都将位于以根模式命名的章节中。

Chapter 3, "Mes­saging Sys­tems," con­tains all of this pat­tern lan­guage's root pat­terns (except Mes­saging, which is in Chapter 2). For an over­view of the pat­tern lan­guage, read (or at least skim) all of the pat­terns in this chapter. To dive deeply on a par­tic­u­lar topic, read its root pat­tern, then go to the pat­terns men­tioned at the end of the pat­tern sec­tion; those next pat­terns will all be in a chapter named after the root pat­tern.

在第 2 章和第 3 章之后，不同类型的消息传递开发人员可能对不同的章节最感兴趣，具体取决于每个组如何使用消息传递执行集成的具体情况：

After Chapters 2 and 3, dif­fer­ent types of mes­saging de­ve­lopers may be most in­ter­ested in dif­fer­ent chapters based on the spe­cif­ics of how each group uses mes­saging to per­form in­teg­ra­tion:

• 系统管理员可能最感兴趣的是第4 章“消息传递通道”（有关创建哪些通道的指南）和第11 章“系统管理”（有关如何维护正在运行的消息传递系统的指南）。

• System ad­min­is­trat­ors may be most in­ter­ested in Chapter 4, "Mes­saging Chan­nels," the guidelines for what chan­nels to create, and Chapter 11, "System Man­age­ment," guid­ance on how to main­tain a run­ning mes­saging system.

• 应用程序开发人员应该查看第 10 章“消息传送端点”，了解如何将应用程序与消息传送系统集成，并查看第5 章“消息构造”，了解何时发送哪些消息。

• Ap­plic­a­tion de­ve­lopers should look at Chapter 10, "Mes­saging En­d­points," to learn how to in­teg­rate an ap­plic­a­tion with a mes­saging system and at Chapter 5, "Mes­sage Con­struc­tion," to learn what mes­sages to send when.

• 系统集成商将从第 7 章“消息路由”如何将消息定向到正确的接收者和第 8 章“消息转换”如何将消息从发送者的格式转换为接收者的格式中获益匪浅。

• System in­teg­rat­ors will gain the most from Chapter 7, "Mes­sage Rout­ing"how to direct mes­sages to the proper re­ceiv­ersand Chapter 8, "Mes­sage Trans­form­a­tion"how to con­vert mes­sages from the sender's format to the re­ceiver's.

请记住，在阅读模式时，如果您很着急，请先阅读问题和解决方案。这将为您提供足够的信息来确定您现在是否对该模式感兴趣以及您是否已经了解该模式。如果您不知道该模式并且听起来很有趣，请继续阅读其他部分。

Keep in mind that when read­ing a pat­tern, if you're in a hurry, start by just read­ing the prob­lem and solu­tion. This will give you enough in­form­a­tion to de­term­ine if the pat­tern is of in­terest to you right now and if you already know the pat­tern. If you do not know the pat­tern and it sounds in­ter­est­ing, go ahead and read the other parts.

还要记住，这是一种模式语言，因此模式不一定要按照书中呈现的顺序来阅读。本书的顺序通过依次考虑所有相关主题并一起讨论相关问题来教您有关消息传递的知识。要使用模式来解决特定问题，请从适当的根模式开始。它的上下文解释了在这一模式之前需要应用哪些模式，即使它们不是本书中紧邻这一模式之前的模式。同样，下一节（模式的最后一段）描述了在本模式之后考虑应用哪些模式，即使它们不是书中紧随本模式之后的模式。使用相互关联的模式网络，而不是线性的书页列表，

Also re­mem­ber that this is a pat­tern lan­guage, so the pat­terns are not ne­ces­sar­ily meant to be read in the order they're presen­ted in the book. The book's order teaches you about mes­saging by con­sid­er­ing all of the rel­ev­ant topics in turn and dis­cuss­ing re­lated issues to­gether. To use the pat­terns to solve a par­tic­u­lar prob­lem, start with an ap­pro­pri­ate root pat­tern. Its con­text ex­plains what pat­terns need to be ap­plied before this one, even if they're not the ones im­me­di­ately pre­ced­ing this one in the book. Like­wise, the next sec­tion (the last para­graph of the pat­tern) de­scribes what pat­terns to con­sider ap­ply­ing after this one, even if they're not the ones im­me­di­ately fol­low­ing this one in the book. Use the web of in­ter­con­nec­ted pat­terns, not the linear list of book pages, to guide you through the ma­ter­ial.

支持网站

Supporting Web Site

请在我们的网站上查找本书的配套信息以及有关企业集成的相关信息：www.enterpriseintegrationpatterns.com。您还可以通过电子邮件将您的意见、建议和反馈发送给我们：authors@enterpriseintegrationpatterns.com。

Please look for com­pan­ion in­form­a­tion to this book plus re­lated in­form­a­tion on en­ter­prise in­teg­ra­tion at our Web site: www.en­ter­pri­sein­teg­ra­tion­pat­terns.com. You can also e-mail your com­ments, sug­ges­tions, and feed­back to us at au­thors@en­ter­pri­sein­teg­ra­tion­pat­terns.com.

概括

Summary

您现在应该很好地理解了以下概念，它们是本书材料的基础：

You should now have a good un­der­stand­ing of the fol­low­ing con­cepts, which are fun­da­mental to the ma­ter­ial in this book:

• 什么是消息传递。

• What mes­saging is.

• 什么是消息系统。

• What a mes­saging system is.

• 为什么要使用消息传递。

• Why to use mes­saging.

• 异步编程与同步编程有何不同。

• How asyn­chron­ous pro­gram­ming is dif­fer­ent from syn­chron­ous pro­gram­ming.

• 应用程序集成与应用程序分发有何不同。

• How ap­plic­a­tion in­teg­ra­tion is dif­fer­ent from ap­plic­a­tion dis­tri­bu­tion.

• 哪些类型的商业产品包含消息传递系统。

• What types of com­mer­cial products con­tain mes­saging sys­tems.

您还应该了解本书将如何教您使用消息传递：

You should also have a feel for how this book is going to teach you to use mes­saging:

• 模式在构建材料中的作用。

• The role pat­terns have in struc­tur­ing the ma­ter­ial.

• 图表中使用的自定义符号的含义。

• The mean­ing of the custom nota­tion used in the dia­grams.

• 示例的目的和范围。

• The pur­pose and scope of the ex­amples.

• 材料的组织。

• The or­gan­iz­a­tion of the ma­ter­ial.

• 如何开始学习该材料。

• How to get star­ted learn­ing the ma­ter­ial.

现在您已经了解了基本概念以及材料的呈现方式，我们邀请您开始学习使用消息传递的企业集成。

Now that you un­der­stand the basic con­cepts and how the ma­ter­ial will be presen­ted, we invite you to start learn­ing about en­ter­prise in­teg­ra­tion using mes­saging.

第 1 章使用模式解决集成问题

Chapter 1. Solving Integration Problems Using Patterns

本章说明了如何使用本书中的模式来解决各种集成问题。为此，我们研究了常见的集成场景并提供了一个全面的集成示例。当我们设计此示例的解决方案时，我们使用本书中包含的模式来表达该解决方案。在本章结束时，您将熟悉大约两打集成模式。

This chapter il­lus­trates how the pat­terns in this book can be used to solve a vari­ety of in­teg­ra­tion prob­lems. In order to do so, we ex­am­ine common in­teg­ra­tion scen­arios and present a com­pre­hens­ive in­teg­ra­tion ex­ample. As we design the solu­tion to this ex­ample, we ex­press the solu­tion using the pat­terns con­tained in this book. At the end of this chapter you will be fa­mil­iar with about two dozen in­teg­ra­tion pat­terns.

整合的必要性

The Need for Integration

企业通常由数百个（如果不是数千个）应用程序组成，这些应用程序是定制的、从第三方获取的、遗留系统的一部分或其组合，在不同操作系统平台的多层中运行。拥有 30 个不同网站、三个 SAP 实例和无数部门解决方案的企业并不罕见。

En­ter­prises are typ­ic­ally com­prised of hun­dreds, if not thou­sands, of ap­plic­a­tions that are custom built, ac­quired from a third party, part of a legacy system, or a com­bin­a­tion thereof, op­er­at­ing in mul­tiple tiers of dif­fer­ent op­er­at­ing system plat­forms. It is not un­com­mon to find an en­ter­prise that has 30 dif­fer­ent Web sites, three in­stances of SAP, and count­less de­part­mental solu­tions.

我们可能会想问：企业如何让自己陷入如此混乱的境地？难道不应该解雇负责这种企业意大利式架构的 CIO 吗？嗯，就像在大多数情况下一样，事情的发生都是有原因的。

We may be temp­ted to ask: How do busi­nesses allow them­selves to get into such a mess? Shouldn't any CIO who is re­spons­ible for such an en­ter­prise spa­ghetti ar­chi­tec­ture be fired? Well, as in most cases, things happen for a reason.

首先，编写业务应用程序很困难。创建一个单一的大型应用程序来运行完整的业务几乎是不可能的。企业资源规划 (ERP) 供应商在创建比以往更大的业务应用程序方面取得了一些成功。但现实是，即使是 SAP、Oracle、Peoplesoft 等重量级企业也只能执行典型企业所需业务功能的一小部分。通过 ERP 系统是当今企业中最流行的集成点之一，我们可以很容易地看出这一点。

First, writ­ing busi­ness ap­plic­a­tions is hard. Cre­at­ing a single, big ap­plic­a­tion to run a com­plete busi­ness is next to im­pos­sible. The En­ter­prise Re­source Plan­ning (ERP) vendors have had some suc­cess at cre­at­ing larger-than-ever busi­ness ap­plic­a­tions. The real­ity, though, is that even the heavy­weights like SAP, Oracle, Peoplesoft, and the like per­form only a frac­tion of the busi­ness func­tions re­quired in a typ­ical en­ter­prise. We can see this easily by the fact that ERP sys­tems are one of the most pop­u­lar in­teg­ra­tion points in today's en­ter­prises.

其次，将业务功能分散到多个应用程序中，使企业能够根据其需求灵活地选择“最佳”会计软件包、“最佳”客户关系管理软件以及“最佳”订单处理系统。通常，IT 组织对完成所有工作的单个企业应用程序不感兴趣，考虑到单个业务需求的数量，这样的应用程序也是不可能的。

Second, spread­ing busi­ness func­tions across mul­tiple ap­plic­a­tions provides the busi­ness with the flex­ib­il­ity to select the "best" ac­count­ing pack­age, the "best" cus­tomer re­la­tion­ship man­age­ment soft­ware, as well as the "best" order-pro­cess­ing system for its needs. Usu­ally, IT or­gan­iz­a­tions are not in­ter­ested in a single en­ter­prise ap­plic­a­tion that does it all, nor is such an ap­plic­a­tion pos­sible given the number of in­di­vidual busi­ness re­quire­ments.

供应商已经学会迎合这种偏好，并围绕特定的核心功能提供有针对性的应用程序。然而，向现有软件包添加新功能的强烈愿望导致了打包业务应用程序之间的一些功能溢出。例如，许多计费系统开始纳入客户服务和会计功能。同样，客户服务软件制造商尝试实施简单的计费功能，例如争议或调整。在系统之间定义清晰的功能分离很困难：客户对账单的争议是否被视为客户服务或计费功能？

Vendors have learned to cater to this pref­er­ence and offer fo­cused ap­plic­a­tions around a spe­cific core func­tion. How­ever, the ever-present urge to add new func­tion­al­ity to ex­ist­ing soft­ware pack­ages has caused some func­tion­al­ity spillover among pack­aged busi­ness ap­plic­a­tions. For ex­ample, many billing sys­tems star­ted to in­cor­por­ate cus­tomer care and ac­count­ing func­tion­al­ity. Like­wise, the cus­tomer care soft­ware maker takes a stab at im­ple­ment­ing simple billing func­tions, such as dis­putes or ad­just­ments. De­fin­ing a clear, func­tional sep­ar­a­tion between sys­tems is dif­fi­cult: Is a cus­tomer dis­pute over a bill con­sidered a cus­tomer care or a billing func­tion?

客户、业务合作伙伴和内部用户等用户在与业务交互时通常不会考虑系统边界。他们执行业务功能，无论业务功能跨越多少个内部系统。例如，客户可以致电更改他或她的地址并查看是否收到最后一笔付款。在许多企业中，这个简单的请求可以跨越客户服务和计费系统。同样，客户下新订单可能需要许多系统的协调。企业需要验证客户 ID、验证客户的良好信誉、检查库存、履行订单、获取运输报价、计算销售税、发送账单等。此过程可以轻松跨越五个或六个不同的系统。

Users such as cus­tom­ers, busi­ness part­ners, and in­ternal users gen­er­ally do not think about system bound­ar­ies when they in­ter­act with a busi­ness. They ex­ecute busi­ness func­tions re­gard­less of how many in­ternal sys­tems the busi­ness func­tion cuts across. For ex­ample, a cus­tomer may call to change his or her ad­dress and see whether the last pay­ment was re­ceived. In many en­ter­prises, this simple re­quest can span across both the cus­tomer care and billing sys­tems. Like­wise, a cus­tomer pla­cing a new order may re­quire the co­ordin­a­tion of many sys­tems. The busi­ness needs to val­id­ate the cus­tomer ID, verify the cus­tomer's good stand­ing, check in­vent­ory, ful­fill the order, get a ship­ping quote, com­pute sales tax, send a bill, and so on. This pro­cess can easily span five or six dif­fer­ent sys­tems. From the cus­tomer's per­spect­ive, it is a single busi­ness trans­ac­tion.

为了支持通用业务流程和跨应用程序的数据共享，需要集成这些应用程序。应用集成需要在多个企业应用之间提供高效、可靠、安全的数据交换。

In order to sup­port common busi­ness pro­cesses and data shar­ing across ap­plic­a­tions, these ap­plic­a­tions need to be in­teg­rated. Ap­plic­a­tion in­teg­ra­tion needs to provide ef­fi­cient, re­li­able, and secure data ex­change between mul­tiple en­ter­prise ap­plic­a­tions.

集成挑战

Integration Challenges

不幸的是，企业集成并不是一件容易的事。根据定义，企业集成必须处理在不同位置的多个平台上运行的多个应用程序，这使得“简单集成”一词几乎是一个矛盾的说法。软件供应商提供企业应用程序集成（EAI）套件，该套件提供跨平台、跨语言集成以及与许多流行的打包业务应用程序接口的能力。然而，这种技术基础设施仅解决了集成复杂性的一小部分。集成的真正挑战涉及业务和技术问题。

Un­for­tu­nately, en­ter­prise in­teg­ra­tion is no easy task. By defin­i­tion, en­ter­prise in­teg­ra­tion has to deal with mul­tiple ap­plic­a­tions run­ning on mul­tiple plat­forms in dif­fer­ent loc­a­tions, making the term simple in­teg­ra­tion pretty much an oxy­moron. Soft­ware vendors offer En­ter­prise Ap­plic­a­tion In­teg­ra­tion (EAI) suites that provide cross-plat­form, cross-lan­guage in­teg­ra­tion as well as the abil­ity to in­ter­face with many pop­u­lar pack­aged busi­ness ap­plic­a­tions. How­ever, this tech­nical in­fra­struc­ture ad­dresses only a small por­tion of the in­teg­ra­tion com­plex­it­ies. The true chal­lenges of in­teg­ra­tion span far across busi­ness and tech­nical issues.

• 企业整合需要企业政治的重大转变。业务应用程序通常专注于特定的功能领域，例如客户关系管理 (CRM)、计费和财务。这似乎是康威著名定律的延伸：“设计系统的组织被迫生产出这些组织通信结构的副本的设计。” 许多 IT 团队都是根据这些相同的职能领域来组织的。成功的企业集成不仅需要在多个计算机系统之间建立通信，而且还需要在集成的企业应用程序中的业务单元和IT部门之间建立通信，

• En­ter­prise in­teg­ra­tion re­quires a sig­ni­fic­ant shift in cor­por­ate polit­ics. Busi­ness ap­plic­a­tions gen­er­ally focus on a spe­cific func­tional area, such as cus­tomer re­la­tion­ship man­age­ment (CRM), billing, and fin­ance. This seems to be an ex­ten­sion of Conway's famous law: "Or­gan­iz­a­tions which design sys­tems are con­strained to pro­duce designs which are copies of the com­mu­nic­a­tion struc­tures of these or­gan­iz­a­tions." Many IT groups are or­gan­ized in align­ment with these same func­tional areas. Suc­cess­ful en­ter­prise in­teg­ra­tion needs to es­tab­lish com­mu­nic­a­tion not only between mul­tiple com­puter sys­tems but also between busi­ness units and IT de­part­mentsin an in­teg­rated en­ter­prise ap­plic­a­tion, groups no longer con­trol a spe­cific ap­plic­a­tion be­cause each ap­plic­a­tion is now part of an over­all flow of in­teg­rated ap­plic­a­tions and ser­vices.

• 由于其范围广泛，集成工作通常会对业务产生深远的影响。一旦最关键业务功能的处理被纳入集成解决方案中，该解决方案的正常运行对于业务就变得至关重要。失败或行为不当的集成解决方案可能会因订单丢失、付款错误和客户不满而给企业造成数百万美元的损失。

• Be­cause of their wide scope, in­teg­ra­tion ef­forts typ­ic­ally have far-reach­ing im­plic­a­tions on the busi­ness. Once the pro­cess­ing of the most crit­ical busi­ness func­tions is in­cor­por­ated into an in­teg­ra­tion solu­tion, the proper func­tion­ing of that solu­tion be­comes vital to the busi­ness. A fail­ing or mis­be­hav­ing in­teg­ra­tion solu­tion can cost a busi­ness mil­lions of dol­lars in lost orders, mis­routed pay­ments, and dis­gruntled cus­tom­ers.

• 开发集成解决方案的一个重要限制是集成开发人员通常对参与的应用程序具有有限的控制能力。在大多数情况下，应用程序是遗留系统或打包应用程序，无法仅为了连接到集成解决方案而进行更改。这通常使集成开发人员处于必须弥补应用程序内部的缺陷或特性或应用程序之间的差异的境地。通常，在应用程序端点内实现部分解决方案会更容易，但由于政治或技术原因，该选项可能不可用。

• One im­port­ant con­straint of de­vel­op­ing in­teg­ra­tion solu­tions is the lim­ited amount of con­trol the in­teg­ra­tion de­ve­lopers typ­ic­ally have over the par­ti­cip­at­ing ap­plic­a­tions. In most cases, the ap­plic­a­tions are legacy sys­tems or pack­aged ap­plic­a­tions that cannot be changed just to be con­nec­ted to an in­teg­ra­tion solu­tion. This often leaves the in­teg­ra­tion de­ve­lopers in a situ­ation where they have to make up for de­fi­cien­cies or idio­syn­crasies inside the ap­plic­a­tions or dif­fer­ences between the ap­plic­a­tions. Often it would be easier to im­ple­ment part of the solu­tion inside the ap­plic­a­tion en­d­points, but for polit­ical or tech­nical reas­ons, that option may not be avail­able.

• 尽管对集成解决方案的需求广泛，但只有少数标准在该领域建立起来。XML、XSL 和 Web 服务的出现无疑标志着集成解决方案中基于标准的功能的最重大进步。然而，围绕 Web 服务的炒作也为市场新的碎片化提供了基础，导致一系列新的标准“扩展”和“解释”。这应该提醒我们，“符合标准”的产品之间缺乏互操作性是 CORBA 的主要障碍之一，而 CORBA 为系统集成提供了复杂的技术解决方案。

• Des­pite the wide­spread need for in­teg­ra­tion solu­tions, only a few stand­ards have es­tab­lished them­selves in this domain. The advent of XML, XSL, and Web ser­vices cer­tainly marks the most sig­ni­fic­ant ad­vance of stand­ards-based fea­tures in an in­teg­ra­tion solu­tion. How­ever, the hype around Web ser­vices has also given grounds to new frag­ment­a­tion of the mar­ket­place, res­ult­ing in a flurry of new "ex­ten­sions" and "in­ter­pret­a­tions" of the stand­ards. This should remind us that the lack of in­ter­op­er­ab­il­ity between "stand­ards-com­pli­ant" products was one of the major stum­bling blocks for CORBA, which offered a soph­ist­ic­ated tech­nical solu­tion for sys­tems in­teg­ra­tion.

• 现有的 XML Web 服务标准仅解决了集成挑战的一小部分。例如，经常声称 XML 是系统集成的通用语言就有些误导。将所有数据交换标准化为 XML 可以比作使用通用字母表（例如罗马字母表）编写所有文档。尽管字母表很常见，但它仍然被用来表示许多语言和方言，而这些语言和方言并不是所有读者都能轻易理解的。企业整合也是如此。通用表示（例如 XML）的存在并不意味着通用语义。“账户”的概念在每个参与系统中可以有许多不同的语义、内涵、约束和假设。

• Ex­ist­ing XML Web ser­vices stand­ards ad­dress only a frac­tion of the in­teg­ra­tion chal­lenges. For ex­ample, the fre­quent claim that XML is the lingua franca of system in­teg­ra­tion is some­what mis­lead­ing. Stand­ard­iz­ing all data ex­change to XML can be likened to writ­ing all doc­u­ments using a common al­pha­bet, such as the Roman al­pha­bet. Even though the al­pha­bet is common, it is still being used to rep­res­ent many lan­guages and dia­lects, which cannot be read­ily un­der­stood by all read­ers. The same is true in en­ter­prise in­teg­ra­tion. The ex­ist­ence of a common present­a­tion (e.g., XML) does not imply common se­mantics. The notion of "ac­count" can have many dif­fer­ent se­mantics, con­nota­tions, con­straints, and as­sump­tions in each par­ti­cip­at­ing system. Resolv­ing se­mantic dif­fer­ences between sys­tems proves to be a par­tic­u­larly dif­fi­cult and time-con­sum­ing task be­cause it in­volves sig­ni­fic­ant busi­ness and tech­nical de­cisions.

• 虽然开发 EAI 解决方案本身具有挑战性，但操作和维护此类解决方案可能更加艰巨。EAI 解决方案的技术组合和分布式特性使得部署、监控和故障排除任务变得复杂，需要多种技能组合。在大多数情况下，这些技能集分布在许多不同的个人中，或者甚至不存在于 IT 运营中。

• While de­vel­op­ing an EAI solu­tion is chal­len­ging in itself, op­er­at­ing and main­tain­ing such a solu­tion can be even more daunt­ing. The mix of tech­no­lo­gies and the dis­trib­uted nature of EAI solu­tions make de­ploy­ment, mon­it­or­ing, and troubleshoot­ing com­plex tasks that re­quire a com­bin­a­tion of skill sets. In most cases, these skill sets are spread across many dif­fer­ent in­di­vidu­als or do not even exist within IT op­er­a­tions.

任何经历过 EAI 部署的人都可以证明，EAI 解决方案是当今企业战略的关键组成部分，但它们使 IT 的生活变得更加困难，而不是更轻松。集成企业的高级愿景（由直通式处理、T+1、敏捷企业等术语定义）和具体实施（System.Messaging.XmlMessageFormatter 的参数是什么）之间还有很长的路要走。再拿一次？）。

Anyone who has been through an EAI de­ploy­ment can attest that EAI solu­tions are a crit­ical com­pon­ent of today's en­ter­prise strategies­but they make IT life harder, not easier. It's a long way between the high-level vision of the in­teg­rated en­ter­prise (defined by terms such as straight-through-pro­cess­ing, T+1, agile en­ter­prise) and the nuts-and-bolts im­ple­ment­a­tions (What para­met­ers did System.Mes­saging.Xm­lMes­sage­Format­ter take again?).

集成模式如何提供帮助

How Integration Patterns Can Help

企业集成没有简单的答案。在我们看来，任何声称集成很容易的人一定非常聪明（或者至少比我们其他人聪明一点），非常无知（好吧，让我们说乐观），或者有经济利益让你相信集成很容易。

There are no simple an­swers for en­ter­prise in­teg­ra­tion. In our opin­ion, anyone who claims that in­teg­ra­tion is easy must be in­cred­ibly smart (or at least a good bit smarter than the rest of us), in­cred­ibly ig­nor­ant (okay, let's say op­tim­istic), or have a fin­an­cial in­terest in making you be­lieve that in­teg­ra­tion is easy.

尽管整合是一个广泛而困难的话题，但我们总是可以观察到一些人在这方面比其他人做得更好。这些人知道哪些其他人不知道的事情？由于没有“21 天自学整合”这样的东西（这本书肯定不是！），这些人不太可能知道整合的所有答案。然而，他们通常已经解决了足够多的集成问题，可以将新问题与之前解决的问题进行比较。他们知道问题的“模式”和相关的解决方案。随着时间的推移，他们通过反复试验或从其他经验丰富的集成架构师那里学习了这些模式。

Even though in­teg­ra­tion is a broad and dif­fi­cult topic, we can always ob­serve some people who are much better at it than others. What do these people know that others don't? Since there is no such thing as "Teach Your­self In­teg­ra­tion in 21 Days" (this book sure ain't!), it is un­likely that these people know all the an­swers to in­teg­ra­tion. How­ever, they have usu­ally solved enough in­teg­ra­tion prob­lems that they can com­pare new prob­lems to prior prob­lems they have solved. They know the "pat­terns" of prob­lems and as­so­ci­ated solu­tions. They learned these pat­terns over time by trial-and-error or from other ex­per­i­enced in­teg­ra­tion ar­chi­tects.

这些模式不是复制粘贴代码示例或收缩包装的组件，而是描述经常出现的问题的解决方案的建议。如果使用得当，集成模式可以帮助填补集成的高级愿景与实际系统实现之间的巨大差距。

The pat­terns are not copy-paste code samples or shrink-wrapped com­pon­ents, but rather nug­gets of advice that de­scribe solu­tions to fre­quently re­cur­ring prob­lems. Used prop­erly, the in­teg­ra­tion pat­terns can help fill the wide gap between the high-level vision of in­teg­ra­tion and the actual system im­ple­ment­a­tion.

广阔的集成世界

The Wide World of Integration

我们有意将集成的定义保留得非常广泛。对我们来说，这意味着连接计算机系统、公司或人员。虽然这个广泛的定义使我们可以方便地将我们感兴趣的任何内容放入本书中，但仔细研究一些最常见的集成场景会很有帮助。在许多集成项目的过程中，我们反复遇到以下六种类型的集成：

We in­ten­tion­ally left the defin­i­tion of in­teg­ra­tion very broad. To us it means con­nect­ing com­puter sys­tems, com­pan­ies, or people. While this broad defin­i­tion gives us the con­veni­ence of stick­ing whatever we find in­ter­est­ing into this book, it is help­ful to have a closer look at some of the most common in­teg­ra­tion scen­arios. Over the course of many in­teg­ra­tion pro­jects, we re­peatedly came across the fol­low­ing six types of in­teg­ra­tion:

• 信息门户

• In­form­a­tion portals

• 数据复制

• Data rep­lic­a­tion

• 共享业务功能

• Shared busi­ness func­tions

• 面向服务的架构

• Ser­vice-ori­ented ar­chi­tec­tures

• 分布式业务流程

• Dis­trib­uted busi­ness pro­cesses

• 企业对企业整合

• Busi­ness-to-busi­ness in­teg­ra­tion

此列表绝不是所有集成的完整分类，但它确实说明了集成架构师构建的解决方案类型。许多集成项目由多种类型的集成组合而成。例如，通常需要复制参考数据，以便将应用程序绑定到单个分布式业务流程中。

This list is by no means a com­plete tax­onomy of all things in­teg­ra­tion, but it does il­lus­trate the kind of solu­tions that in­teg­ra­tion ar­chi­tects build. Many in­teg­ra­tion pro­jects con­sist of a com­bin­a­tion of mul­tiple types of in­teg­ra­tion. For ex­ample, ref­er­ence data rep­lic­a­tion is often re­quired in order to tie ap­plic­a­tions into a single, dis­trib­uted busi­ness pro­cess.

信息门户

In­form­a­tion Portal

许多业务用户必须访问多个系统才能回答特定问题或执行一项业务功能。例如，为了验证订单的状态，客户服务代表可能必须访问大型机上的订单管理系统并登录到管理通过 Web 下达的订单的系统。信息门户将来自多个源的信息聚合到单个显示中，以避免用户访问多个系统来获取信息。简单的信息门户将屏幕划分为多个区域，每个区域显示来自不同系统的信息。更复杂的系统在区域之间提供有限的交互；例如，当用户从区域 A 的列表中选择一个项目时，区域 B 刷新并显示有关所选项目的详细信息。其他门户提供更复杂的用户交互，并模糊了门户和集成应用程序之间的界限。

Many busi­ness users have to access more than one system to answer a spe­cific ques­tion or to per­form a single busi­ness func­tion. For ex­ample, to verify the status of an order, a cus­tomer ser­vice rep­res­ent­at­ive may have to access the order man­age­ment system on the main­frame plus log on to the system that man­ages orders placed over the Web. In­form­a­tion portals ag­greg­ate in­form­a­tion from mul­tiple sources into a single dis­play to avoid having the user access mul­tiple sys­tems for in­form­a­tion. Simple in­form­a­tion portals divide the screen into mul­tiple zones, each of which dis­plays in­form­a­tion from a dif­fer­ent system. More soph­ist­ic­ated sys­tems provide lim­ited in­ter­ac­tion between zones; for ex­ample, when a user se­lects an item from a list in zone A, zone B re­freshes with de­tailed in­form­a­tion about the se­lec­ted item. Other portals provide even more soph­ist­ic­ated user in­ter­ac­tion and blur the line between a portal and an in­teg­rated ap­plic­a­tion.

数据复制

Data Rep­lic­a­tion

许多业务系统需要访问相同的数据。例如，客户的地址可能会用在客户服务系统（当客户致电更改地址时）、会计系统（计算销售税）、运输系统（为货物贴上标签）和计费系统（以发送发票）。其中许多系统都有自己的数据存储来存储与客户相关的信息。当客户致电更改其地址时，所有这些系统都需要更改其客户地址的副本。这可以通过实施基于数据复制的集成策略来实现。

Many busi­ness sys­tems re­quire access to the same data. For ex­ample, a cus­tomer's ad­dress may be used in the cus­tomer care system (when the cus­tomer calls to change it), the ac­count­ing system (to com­pute sales tax), the ship­ping system (to label the ship­ment), and the billing system (to send an in­voice). Many of these sys­tems have their own data stores to store cus­tomer-re­lated in­form­a­tion. When a cus­tomer calls to change his or her ad­dress, all these sys­tems need to change their copy of the cus­tomer's ad­dress. This can be ac­com­plished by im­ple­ment­ing an in­teg­ra­tion strategy based on data rep­lic­a­tion.

有许多不同的方法来实现数据复制。例如，一些数据库供应商在数据库中内置了复制功能；或者，我们可以将数据导出到文件中，然后将它们重新导入到其他系统，或者我们可以使用面向消息的中间件来传输消息内的数据记录。

There are many dif­fer­ent ways to im­ple­ment data rep­lic­a­tion. For ex­ample, some data­base vendors build rep­lic­a­tion func­tions into the data­base; al­tern­at­ively, we can export data into files and re-import them to the other system, or we can use mes­sage-ori­ented mid­dle­ware to trans­port data re­cords inside mes­sages.

共享业务功能

Shared Busi­ness Func­tion

就像许多业务应用程序存储冗余数据一样，它们也倾向于实现冗余功能。多个系统可能需要检查社会安全号码是否有效、地址是否与指定的邮政编码匹配，或者特定商品是否有库存。将这些功能公开为共享业务功能是有意义的，该功能只需实现一次即可作为服务提供给其他系统。

In the same way that many busi­ness ap­plic­a­tions store re­dund­ant data, they also tend to im­ple­ment re­dund­ant func­tion­al­ity. Mul­tiple sys­tems may need to check whether a social-se­cur­ity number is valid, whether the ad­dress matches the spe­cified postal code, or whether a par­tic­u­lar item is in stock. It makes sense to expose these func­tions as a shared busi­ness func­tion that is im­ple­men­ted once and avail­able as a ser­vice to other sys­tems.

共享业务功能可以满足一些与数据复制相同的需求。例如，我们可以实现一个名为“获取客户地址”的业务功能，该功能允许其他系统在需要时请求客户的地址，而不是永久存储冗余副本。这两种方法之间的决定是由许多标准驱动的，例如我们对系统的控制量（调用共享函数通常比将数据加载到数据库更具侵入性）或变化率（地址可能会改变）。经常需要但很少改变）。

A shared busi­ness func­tion can ad­dress some of the same needs as data rep­lic­a­tion. For ex­ample, we could im­ple­ment a busi­ness func­tion called Get Cus­tomer Ad­dress that could allow other sys­tems to re­quest the cus­tomer's ad­dress when it is needed rather than per­man­ently store a re­dund­ant copy. The de­cision between these two ap­proaches is driven by a number of cri­teria, such as the amount of con­trol we have over the sys­tems (call­ing a shared func­tion is usu­ally more in­trus­ive than load­ing data into the data­base) or the rate of change (an ad­dress may be needed fre­quently but change very in­fre­quently).

面向服务的架构

Ser­vice-Ori­ented Ar­chi­tec­ture

共享业务功能通常称为服务。服务是一种定义明确的功能，普遍可用并响应“服务消费者”的请求。一旦企业组装了有用服务的集合，管理服务就成为一项关键功能。首先，应用程序需要某种形式的服务目录，即所有可用服务的集中列表。其次，每个服务需要以应用程序可以与服务“协商”通信合同的方式描述其接口。服务发现和协商这两个功能是构成面向服务的体系结构 (SOA) 的关键要素。

Shared busi­ness func­tions are often re­ferred to as ser­vices. A ser­vice is a well-defined func­tion that is uni­ver­sally avail­able and re­sponds to re­quests from "ser­vice con­sumers." Once an en­ter­prise as­sembles a col­lec­tion of useful ser­vices, man­aging the ser­vices be­comes a crit­ical func­tion. First, ap­plic­a­tions need some form of ser­vice dir­ect­ory, a cent­ral­ized list of all avail­able ser­vices. Second, each ser­vice needs to de­scribe its in­ter­face in such a way that an ap­plic­a­tion can "ne­go­ti­ate" a com­mu­nic­a­tions con­tract with the ser­vice. These two func­tions, ser­vice dis­cov­ery and ne­go­ti­ation, are the key ele­ments that make up a ser­vice-ori­ented ar­chi­tec­ture (SOA).

SOA 模糊了集成和分布式应用程序之间的界限。可以使用其他应用程序提供的现有远程服务来开发新的应用程序。因此，调用服务可以认为是两个应用程序之间的集成。然而，大多数 SOA 提供的工具使调用外部服务几乎与调用本地方法一样简单（抛开性能考虑），因此在 SOA 之上开发应用程序的过程类似于构建分布式应用程序。

SOAs blur the line between in­teg­ra­tion and dis­trib­uted ap­plic­a­tions. A new ap­plic­a­tion can be de­ve­loped using ex­ist­ing remote ser­vices that may be provided by other ap­plic­a­tions. There­fore, call­ing a ser­vice can be con­sidered in­teg­ra­tion between the two ap­plic­a­tions. How­ever, most SOAs provide tools that make call­ing an ex­ternal ser­vice almost as simple as call­ing a local method (per­form­ance con­sid­er­a­tions aside), so that the pro­cess of de­vel­op­ing an ap­plic­a­tion on top of an SOA re­sembles build­ing a dis­trib­uted ap­plic­a­tion.

分布式业务流程

Dis­trib­uted Busi­ness Pro­cess

集成的关键驱动因素之一是单个业务事务通常分布在许多不同的系统中。前面的例子向我们展示了一个简单的业务功能（例如下订单）可以轻松地触及六个系统。在大多数情况下，所有相关功能都包含在现有应用程序中。缺少的是这些应用程序之间的协调。因此，我们可以添加一个业务流程管理组件来管理跨多个现有系统的业务功能的执行。

One of the key drivers of in­teg­ra­tion is that a single busi­ness trans­ac­tion is often spread across many dif­fer­ent sys­tems. A pre­vi­ous ex­ample showed us that a simple busi­ness func­tion such as pla­cing an order can easily touch half a dozen sys­tems. In most cases, all rel­ev­ant func­tions are in­cor­por­ated inside ex­ist­ing ap­plic­a­tions. What is miss­ing is the co­ordin­a­tion between these ap­plic­a­tions. There­fore, we can add a busi­ness pro­cess man­age­ment com­pon­ent that man­ages the ex­e­cu­tion of a busi­ness func­tion across mul­tiple ex­ist­ing sys­tems.

SOA 和分布式业务之间的界限可能是模糊的。例如，您可以将所有相关业务功能公开为服务，然后在通过 SOA 访问所有服务的应用程序内对业务流程进行编码。

The bound­ar­ies between an SOA and a dis­trib­uted busi­ness can be fuzzy. For ex­ample, you could expose all rel­ev­ant busi­ness func­tions as ser­vices and then encode the busi­ness pro­cess inside an ap­plic­a­tion that ac­cesses all ser­vices via an SOA.

企业对企业整合

Busi­ness-to-Busi­ness In­teg­ra­tion

到目前为止，我们主要考虑的是单个企业内部应用程序和业务功能之间的交互。在许多情况下，业务功能可以从外部供应商或业务合作伙伴处获得。例如，运输公司可以为客户提供计算运输成本或跟踪运输的服务。或者，企业可以使用外部提供商来计算销售税率。同样，业务合作伙伴之间也经常发生整合。顾客可以联系零售商询问商品的价格和库存情况。作为回应，零售商可以向供应商询问包含缺货商品的预期发货的状态。

So far, we have mainly con­sidered the in­ter­ac­tion between ap­plic­a­tions and busi­ness func­tions inside a single en­ter­prise. In many cases, busi­ness func­tions may be avail­able from out­side sup­pli­ers or busi­ness part­ners. For ex­ample, the ship­ping com­pany may provide a ser­vice for cus­tom­ers to com­pute ship­ping cost or track ship­ments. Or a busi­ness may use an out­side pro­vider to com­pute sales tax rates. Like­wise, in­teg­ra­tion fre­quently occurs between busi­ness part­ners. A cus­tomer may con­tact a re­tailer to in­quire on the price and avail­ab­il­ity of an item. In re­sponse, the re­tailer may ask the sup­plier for the status of an ex­pec­ted ship­ment that con­tains the out-of-stock item.

上述许多考虑因素同样适用于企业对企业的集成。然而，通过互联网或其他网络进行通信通常会引发与传输协议和安全性相关的新问题。此外，由于许多业务合作伙伴可能在电子“对话”中进行协作，因此标准化数据格式至关重要。

Many of the above con­sid­er­a­tions apply equally to busi­ness-to-busi­ness in­teg­ra­tion. How­ever, com­mu­nic­at­ing across the In­ter­net or some other net­work usu­ally raises new issues re­lated to trans­port pro­to­cols and se­cur­ity. Also, since many busi­ness part­ners may col­lab­or­ate in an elec­tronic "con­ver­sa­tion," stand­ard­ized data formats are crit­ic­ally im­port­ant.

松耦合

Loose Coupling

企业架构和集成中最流行的术语之一是松耦合。事实上，这是一个非常流行的术语，以至于 Doug Kaye 写了一整本书，以这个无处不在的概念为标题 [ Kaye ]。松耦合的好处早已为人所知，但由于 Web 服务架构的迅速普及，它们最近才成为人们关注的焦点。

One of the biggest buzzwords in en­ter­prise ar­chi­tec­ture and in­teg­ra­tion is loose coup­ling. It is in fact such a pop­u­lar term that Doug Kaye wrote a whole book titled after this ubi­quit­ous concept [Kaye]. The be­ne­fits of loose coup­ling have been known for quite some time now, but they have taken center stage more re­cently due to the sur­ging pop­ular­ity of Web ser­vices ar­chi­tec­tures.

松耦合背后的核心原则是减少两方（组件、应用程序、服务、程序、用户）在交换信息时对彼此所做的假设。两方对彼此和通用协议做出的假设越多，通信的效率就越高，但解决方案对中断或更改的容忍度就越低，因为双方彼此紧密耦合。

The core prin­ciple behind loose coup­ling is to reduce the as­sump­tions two parties (com­pon­ents, ap­plic­a­tions, ser­vices, pro­grams, users) make about each other when they ex­change in­form­a­tion. The more as­sump­tions two parties make about each other and the common pro­tocol, the more ef­fi­cient the com­mu­nic­a­tion can be, but the less tol­er­ant the solu­tion is of in­ter­rup­tions or changes be­cause the parties are tightly coupled to each other.

紧耦合的一个很好的例子是本地方法调用。在应用程序内调用本地方法基于被调用例程和调用例程之间的许多假设。两种方法都必须在同一进程（例如虚拟机）中运行并以相同语言编写（或至少使用通用中间语言或字节代码）。调用方法必须使用商定的数据类型传递确切数量的预期参数。通话是即时的；也就是说，被调用方法在调用方法调用后立即开始处理。同时，只有当被调用方法完成时，调用方法才会恢复处理（意味着调用是同步的）。处理将在调用方法中自动恢复，并紧随方法调用后的语句。方法之间的通信是立即且瞬时的，因此调用者和被调用方法都不必担心第三方窃听形式的安全漏洞。所有这些假设使得编写结构良好的应用程序变得非常容易，这些应用程序将功能划分为单独的方法以供其他方法调用。由此产生的大量小方法可以实现灵活性和重用。所有这些假设使得编写结构良好的应用程序变得非常容易，这些应用程序将功能划分为单独的方法以供其他方法调用。由此产生的大量小方法可以实现灵活性和重用。所有这些假设使得编写结构良好的应用程序变得非常容易，这些应用程序将功能划分为单独的方法以供其他方法调用。由此产生的大量小方法可以实现灵活性和重用。

A great ex­ample of tight coup­ling is a local method in­voc­a­tion. In­vok­ing a local method inside an ap­plic­a­tion is based on a lot of as­sump­tions between the called and the call­ing routine. Both meth­ods have to run in the same pro­cess (e.g., a vir­tual ma­chine) and be writ­ten in the same lan­guage (or at least use a common in­ter­me­di­ate lan­guage or byte code). The call­ing method has to pass the exact number of ex­pec­ted para­met­ers using agreed-upon data types. The call is im­me­di­ate; that is, the called method starts pro­cess­ing im­me­di­ately after the call­ing method makes the call. Mean­while, the call­ing method will resume pro­cess­ing only when the called method com­pletes (mean­ing the in­voc­a­tion is syn­chron­ous). Pro­cess­ing will auto­mat­ic­ally resume in the call­ing method with the state­ment im­me­di­ately fol­low­ing the method call. The com­mu­nic­a­tion between the meth­ods is im­me­di­ate and in­stant­an­eous, so neither the caller nor the called method has to worry about se­cur­ity breaches in the form of eaves­drop­ping third parties. All these as­sump­tions make it very easy to write well-struc­tured ap­plic­a­tions that divide func­tion­al­ity into in­di­vidual meth­ods to be called by other meth­ods. The res­ult­ing large number of small meth­ods allows for flex­ib­il­ity and reuse.

许多集成方法旨在通过将远程数据交换封装成与本地方法调用相同的语义来使远程通信变得简单。这种策略产生了远程过程调用（RPC）或远程方法调用（RMI）的概念，许多流行的框架和平台都支持这种概念：CORBA（参见 [ Zahavi])、Microsoft DCOM、.NET Remoting、Java RMI 以及最近的 RPC 风格的 Web 服务。这种方法的预期好处是双重的。首先，同步方法调用语义对于应用程序开发人员来说非常熟悉，那么为什么不建立在我们已经知道的基础上呢？其次，对本地方法调用和远程调用使用相同的语法和语义将使我们能够将哪些组件应在本地运行、哪些组件应远程运行的决定推迟到部署时，从而使应用程序开发人员少担心一件事。

Many in­teg­ra­tion ap­proaches have aimed to make remote com­mu­nic­a­tions simple by pack­aging a remote data ex­change into the same se­mantics as a local method call. This strategy res­ul­ted in the notion of a Remote Pro­ced­ure Call (RPC) or Remote Method In­voc­a­tion (RMI), sup­por­ted by many pop­u­lar frame­works and plat­forms: CORBA (see [Zahavi]), Mi­crosoft DCOM, .NET Re­mot­ing, Java RMI, and most re­cently, RPC-style Web ser­vices. The in­ten­ded upside of this ap­proach is two­fold. First, syn­chron­ous method-call se­mantics are very fa­mil­iar to ap­plic­a­tion de­ve­lopers, so why not build on what we already know? Second, using the same syntax and se­mantics for both local method calls and remote in­voc­a­tions would allow us to defer until de­ploy­ment time the de­cision about which com­pon­ents should run loc­ally and which should run re­motely, leav­ing the ap­plic­a­tion de­ve­loper with one less thing to worry about.

所有这些方法面临的挑战在于远程通信使本地方法调用所基于的许多假设无效。因此，将远程通信抽象为方法调用的简单语义可能会造成混乱和误导。Waldo 和同事早在 1994 年就提醒我们，“在分布式系统中交互的对象需要以与在单个地址空间中交互的对象本质上不同的方式进行处理”[ Waldo]。例如，如果我们调用远程服务来为我们执行某个功能，我们真的想将自己限制为仅使用与我们使用的相同编程语言构建的那些服务吗？通过网络进行的呼叫往往也比本地呼叫慢多个数量级。调用方法真的应该等到被调用方法完成吗？如果网络中断，调用的方法暂时无法访问怎么办？我们应该等多久？我们如何确保我们与目标方而不是第三方“欺骗者”进行通信？我们如何防止窃听？如果被调用方法的方法签名（预期参数列表）发生变化怎么办？如果远程方法由第三方或业务合作伙伴维护，我们不再能够控制此类变化。我们应该让我们的方法调用失败，还是应该尝试找到参数之间的最佳可能映射并仍然进行调用？很快就会发现，远程集成带来了许多本地方法调用从未处理过的问题。

The chal­lenge that all these ap­proaches face lies in the fact that remote com­mu­nic­a­tion in­val­id­ates many of the as­sump­tions that a local method call is based on. As a result, ab­stract­ing the remote com­mu­nic­a­tion into the simple se­mantics of a method call can be con­fus­ing and mis­lead­ing. Waldo and col­leagues re­minded us back in 1994 that "ob­jects that in­ter­act in a dis­trib­uted system need to be dealt with in ways that are in­trins­ic­ally dif­fer­ent from ob­jects that in­ter­act in a single ad­dress space" [Waldo]. For ex­ample, if we call a remote ser­vice to per­form a func­tion for us, do we really want to re­strict ourselves to only those ser­vices that were built using the same pro­gram­ming lan­guage we use? A call across the net­work also tends to be mul­tiple orders of mag­nitude slower than a local call. Should the call­ing method really wait until the called method com­pletes? What if the net­work is in­ter­rup­ted and the called method is tem­por­ar­ily un­reach­able? How long should we wait? How can we be sure we com­mu­nic­ate with the in­ten­ded party and not a third-party "spoofer"? How can we pro­tect against eaves­drop­ping? What if the method sig­na­ture (the list of ex­pec­ted para­met­ers) of the called method changes? If the remote method is main­tained by a third party or a busi­ness part­ner, we no longer have con­trol over such changes. Should we have our method in­voc­a­tion fail, or should we at­tempt to find the best pos­sible map­ping between the para­met­ers and still make the call? It quickly be­comes ap­par­ent that remote in­teg­ra­tion brings up a lot of issues that a local method call never had to deal with.

总之，试图将远程通信描述为本地方法调用的变体是自找麻烦。这种紧密耦合的架构通常会导致解决方案脆弱、难以维护且可扩展性差。许多 Web 服务先驱最近（重新）艰难地发现了这一事实。

In sum­mary, trying to por­tray remote com­mu­nic­a­tion as a vari­ant of a local method in­voc­a­tion is asking for trouble. Such tightly coupled ar­chi­tec­tures typ­ic­ally result in brittle, hard-to-main­tain, and poorly scal­able solu­tions. Many Web ser­vices pi­on­eers re­cently (re-)dis­covered this fact the hard way.

一分钟 EAI

One-Minute EAI

为了展示紧密耦合依赖关系的影响以及如何解决它们，让我们看一下连接两个系统的非常简单的方法。假设我们正在构建一个网上银行系统，允许客户从另一家银行将钱存入他们的帐户。为了执行此功能，前端 Web 应用程序必须与管理资金转移的后端财务系统集成。

To show the ef­fects of tightly coupled de­pend­en­cies and how to re­solve them, let's look at a very simple way of con­nect­ing two sys­tems. Let's assume we are build­ing an online bank­ing system that allows cus­tom­ers to de­posit money into their ac­count from an­other bank. To per­form this func­tion, the front-end Web ap­plic­a­tion has to be in­teg­rated with the back-end fin­an­cial system that man­ages fund trans­fers.

连接两个系统最简单的方法是通过 TCP/IP 协议。过去 15 年中创建的每一个有自尊的操作系统或编程库都肯定包含 TCP/IP 堆栈。TCP/IP 是一种普遍存在的通信协议，可在连接到 Internet 和本地网络的数百万台计算机之间传输数据。为什么不使用最普遍的网络协议在两个应用程序之间进行通信？

The easi­est way to con­nect the two sys­tems is through the TCP/IP pro­tocol. Every self-re­spect­ing op­er­at­ing system or pro­gram­ming lib­rary cre­ated in the last 15 years is cer­tain to in­clude a TCP/IP stack. TCP/IP is the ubi­quit­ous com­mu­nic­a­tions pro­tocol that trans­ports data between the mil­lions of com­puters con­nec­ted to the In­ter­net and local net­works. Why not use the most ubi­quit­ous of all net­work pro­to­cols to com­mu­nic­ate between two ap­plic­a­tions?

为了简单起见，我们假设将钱存入某人帐户的远程函数仅使用此人的姓名和美元金额作为参数。以下几行代码足以通过 TCP/IP 调用此类函数（我们选择了 C#，但此代码在 C 或 Java 中看起来几乎相同）。

To keep things simple, let's assume that the remote func­tion that de­pos­its money into a person's ac­count takes only the person's name and the dollar amount as ar­gu­ments. The fol­low­ing few lines of code suf­fice to call such a func­tion over TCP/IP (we chose C#, but this code would look vir­tu­ally identical in C or Java).

String 主机名 = "finance.bank.com";
国际端口=80；

IPHostEntry 主机信息 = Dns.GetHostByName(主机名);
IPAddress 地址 = hostInfo.AddressList[0];

IPEndPoint 端点 = new IPEndPoint(地址, 端口);

Socket套接字 = new Socket(address.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
套接字.Connect(端点);

byte[] 金额 = BitConverter.GetBytes(1000);
byte[] name = Encoding.ASCII.GetBytes("Joe");

int bytesSent = socket.Send(金额);
bytesSent += socket.Send(名称);

套接字.关闭();

String host­Name = "fin­ance.bank.com";
int port = 80;

IPHos­tEn­try hostInfo = Dns.GetH­ost­By­Name(host­Name);
IPAd­dress ad­dress = hostInfo.Ad­dress­List[0];

IPEnd­Point en­d­point = new IPEnd­Point(ad­dress, port);

Socket socket = new Socket(ad­dress.Ad­dress­Fam­ily, Sock­et­Type.Stream, Pro­to­col­Type.Tcp);
socket.Con­nect(en­d­point);

byte[] amount = Bit­Con­verter.Get­Bytes(1000);
byte[] name   = En­cod­ing.ASCII.Get­Bytes("Joe");

int bytes­Sent = socket.Send(amount);
bytes­Sent    += socket.Send(name);

socket.Close();

此代码打开到地址Finance.bank.com 的套接字连接，并通过网络发送两个数据项（金额和客户姓名）。不需要昂贵的中间件：不需要EAI工具，RPC工具包只需10行代码。当我们运行此代码时，它告诉我们“已发送 7 个字节”。瞧！整合怎么会那么困难呢？

This code opens a socket con­nec­tion to the ad­dress fin­ance.bank.com and sends two data items (the amount and the cus­tomer's name) across the net­work. No ex­pens­ive mid­dle­ware is re­quired: no EAI tools, RPC toolkit­s­just 10 lines of code. When we run this code, it tells us "7 bytes sent." Voila! How can in­teg­ra­tion be dif­fi­cult?

这种集成尝试存在几个主要问题。TCP/IP 协议的优势之一是其广泛的支持，因此我们可以连接到几乎任何连接到网络的计算机，无论其使用什么操作系统或编程语言。然而，平台无关性仅适用于非常简单的消息：字节流。为了将数据转换为字节流，我们使用了BitConverter班级。此类使用数据类型的内部存储器表示形式将任何数据类型转换为字节数组。问题是整数的内部表示因计算机系统而异。例如，.NET 使用 32 位整数，而其他系统可能使用 64 位表示。我们的示例通过网络传输 4 个字节来表示 32 位整数。使用 64 位的系统倾向于从网络读取 8 个字节，最终将整个消息（包括客户名称）解释为单个数字。

There are a couple of major prob­lems with this in­teg­ra­tion at­tempt. One of the strengths of the TCP/IP pro­tocol is its wide sup­port so that we can con­nect to pretty much any com­puter con­nec­ted to the net­work re­gard­less of the op­er­at­ing system or pro­gram­ming lan­guage it uses. How­ever, the plat­form-in­de­pend­ence works only for very simple mes­sages: byte streams. In order to con­vert our data into a byte stream, we used the Bit­Con­verter class. This class con­verts any data type into a byte array, using the in­ternal memory rep­res­ent­a­tion of the data type. The catch is that the in­ternal rep­res­ent­a­tion of an in­teger number varies with com­puter sys­tems. For ex­ample, .NET uses a 32-bit in­teger, while other sys­tems may use a 64-bit rep­res­ent­a­tion. Our ex­ample trans­fers 4 bytes across the net­work to rep­res­ent a 32-bit in­teger number. A system using 64 bits would be in­clined to read 8 bytes off the net­work and would end up in­ter­pret­ing the whole mes­sage (in­clud­ing the cus­tomer name) as a single number.

此外，一些计算机系统以大端格式存储数字，而另一些计算机系统以小端格式存储数字。大端格式首先存储从最高字节开始的数字，而小端系统首先存储最低字节。PC 采用小端模式运行，因此代码通过网络传递以下 4 个字节：

Also, some com­puter sys­tems store their num­bers in big-endian format, while others store them in little-endian format. A big-endian format stores num­bers start­ing with the highest byte first, while little-endian sys­tems store the lowest byte first. PCs op­er­ate on a little-endian scheme so that the code passes the fol­low­ing 4 bytes across the net­work:

232 3 0 0

232  3  0  0

232 + 3 * 2 ⁸等于 1,000。使用大端数字的系统会认为此消息表示 232 * 2 ²⁴ + 3 * 2 ¹⁶ = 3,892,510,720。乔将成为一个非常富有的人！因此，这种方法仅在所有连接的计算机以相同内部格式表示数字的假设下才有效。

232 + 3 * 2⁸ equals 1,000. A system that uses big-endian num­bers would con­sider this mes­sage to mean 232 * 2²⁴ + 3 * 2¹⁶ = 3,892,510,720. Joe will be a very rich man! So this ap­proach works only under the as­sump­tion that all con­nec­ted com­puters rep­res­ent num­bers in the same in­ternal format.

这种简单方法的第二个问题是我们指定远程计算机的位置（在我们的例子中为finance.bank.com）。动态命名服务 (DNS) 为我们提供了域名和 IP 地址之间的一级间接寻址，但如果我们想将该功能移至不同域中的另一台计算机上该怎么办？如果机器出现故障并且我们必须设置另一台机器怎么办？如果我们想将信息发送到多台机器怎么办？对于每种情况，我们都必须更改代码。如果我们使用很多远程功能，这可能会变得非常乏味。因此，我们应该找到一种方法，使我们的通信独立于网络上的特定机器。

The second prob­lem with this simple ap­proach is that we spe­cify the loc­a­tion of the remote ma­chine (in our case, fin­ance.bank.com). The Dy­namic Naming Ser­vice (DNS) gives us one level of in­dir­ec­tion between the domain name and the IP ad­dress, but what if we want to move the func­tion to a dif­fer­ent com­puter on a dif­fer­ent domain? What if the ma­chine fails and we have to set up an­other ma­chine? What if we want to send the in­form­a­tion to more than one ma­chine? For each scen­ario, we would have to change the code. If we use a lot of remote func­tions, this could become very te­di­ous. So, we should find a way to make our com­mu­nic­a­tion in­de­pend­ent from a spe­cific ma­chine on the net­work.

我们的简单 TCP/IP 示例还在两台机器之间建立了时间依赖性。TCP/IP 是一种面向连接的协议。在传输任何数据之前，必须首先建立连接。建立 TCP 连接涉及 IP 数据包在发送方和接收方之间来回传输。这就要求机器和网络同时可用。如果这三个部分中的任何一个出现故障或由于高负载而无法使用，则无法发送数据。

Our simple TCP/IP ex­ample also es­tab­lishes tem­poral de­pend­en­cies between the two ma­chines. TCP/IP is a con­nec­tion-ori­ented pro­tocol. Before any data can be trans­ferred, a con­nec­tion has to be es­tab­lished first. Es­tab­lish­ing a TCP con­nec­tion in­volves IP pack­ets trav­el­ing back and forth between sender and re­ceiver. This re­quires that both ma­chines and the net­work are all avail­able at the same time. If any of the three pieces is mal­func­tion­ing or not avail­able due to high load, the data cannot be sent.

最后，简单的通信还依赖于非常严格的数据格式。我们发送 4 个字节的金额数据，然后发送定义客户帐户的字符序列。如果我们想插入第三个参数，例如货币名称，我们必须修改发送者和接收者以使用新的数据格式。

Fi­nally, the simple com­mu­nic­a­tion also relies on a very strict data format. We are send­ing 4 bytes of amount data and then a se­quence of char­ac­ters that define the cus­tomer's ac­count. If we want to insert a third para­meter, such as the name of the cur­rency, we would have to modify both sender and re­ceiver to use the new data format.

紧耦合交互

Tightly Coupled In­ter­ac­tion

我们的极简集成解决方案既快速又便宜，但它会导致一个非常脆弱的解决方案，因为两个参与方对彼此做出以下假设：

Our min­im­al­ist in­teg­ra­tion solu­tion is fast and cheap, but it res­ults in a very brittle solu­tion be­cause the two par­ti­cip­at­ing parties make the fol­low­ing as­sump­tions about each other:

• 数字和对象的平台技术 内部表示

• Plat­form tech­no­logy in­ternal rep­res­ent­a­tions of num­bers and ob­jects

• 位置 硬编码机器地址

• Loc­a­tion hard­coded ma­chine ad­dresses

• 所有组件必须同时可用的时间

• Time all com­pon­ents have to be avail­able at the same time

• 数据格式参数 列表及其类型必须匹配

• Data format the list of para­met­ers and their types must match

正如我们之前所说，耦合是衡量各方在沟通时对彼此做出多少假设的指标。我们的简单解决方案需要各方做出很多假设。因此，该解决方案是紧耦合的。

As we stated earlier, coup­ling is a meas­ure of how many as­sump­tions parties make about each other when they com­mu­nic­ate. Our simple solu­tion re­quires the parties to make a lot of as­sump­tions. There­fore, this solu­tion is tightly coupled.

为了使解决方案更加松散耦合，我们可以尝试将这些依赖项一一删除。我们应该使用一种自描述且与平台无关的标准数据格式，例如XML。我们不应该将信息直接发送到特定的机器，而应该将其发送到可寻址的通道。通道是发送者和接收者可以在不知道彼此身份的情况下达成一致的逻辑地址。使用通道可以解决位置依赖性，但如果通道是使用面向连接的协议实现的，则仍然需要所有组件同时可用。为了消除这种时间依赖性，我们可以增强通道以对发送的请求进行排队，直到网络和接收系统准备就绪。发送者现在可以将请求发送到通道中并继续处理，而不必担心数据的传递。在通道内对请求进行排队需要将数据分块为独立的消息以便通道知道在任一时间要缓冲和传送多少数据。这两个系统仍然依赖于通用的数据格式，但我们可以通过允许通道内的数据格式转换来消除这种依赖性。如果一个系统的格式发生变化，我们只需要改变变压器，而不需要改变其他参与的系统。如果许多应用程序将数据发送到同一通道，这尤其有用

In order to make the solu­tion more loosely coupled, we can try to remove these de­pend­en­cies one by one. We should use a stand­ard data format that is self-de­scrib­ing and plat­form-in­de­pend­ent, such as XML. In­stead of send­ing in­form­a­tion dir­ectly to a spe­cific ma­chine, we should send it to an ad­dress­able chan­nel. A chan­nel is a lo­gical ad­dress that both sender and re­ceiver can agree on without being aware of each other's iden­tity. Using chan­nels re­solves the loc­a­tion de­pend­ency but still re­quires all com­pon­ents to be avail­able at the same time if the chan­nel is im­ple­men­ted using a con­nec­tion-ori­ented pro­tocol. In order to remove this tem­poral de­pend­ency, we can en­hance the chan­nel to queue up sent re­quests until the net­work and the re­ceiv­ing system are ready. The sender can now send re­quests into the chan­nel and con­tinue pro­cess­ing without having to worry about the de­liv­ery of the data. Queuing re­quests inside the chan­nel re­quires data to be chunked into self-con­tained mes­sages so that the chan­nel knows how much data to buffer and de­liver at any one time. The two sys­tems still depend on a common data format, but we can remove this de­pend­ency by al­low­ing for data format trans­form­a­tions inside the chan­nel. If the format of one system changes, we only have to change the trans­former and not the other par­ti­cip­at­ing sys­tems. This is par­tic­u­larly useful if many ap­plic­a­tions send data to the same chan­nel

松耦合交互

Loosely Coupled In­ter­ac­tion

通用数据格式、跨队列通道的异步通信和变压器等机制有助于将紧密耦合的解决方案转变为松散耦合的解决方案。发送方不再需要依赖接收方的内部数据格式或其位置。它甚至不必关注另一台计算机是否准备好接受请求。消除系统之间的这些依赖关系使整体解决方案更能容忍变化，这是松散耦合的主要好处。松散耦合方法的主要缺点是增加了复杂性。这不再是 10 行代码的解决方案！因此，我们使用面向消息的中间件为我们提供这些服务的基础设施。这种基础设施使得以松散耦合的方式交换数据几乎与我们开始的示例一样简单。下一节将介绍构成此类中间件解决方案的组件。

Mech­an­isms such as a common data format, asyn­chron­ous com­mu­nic­a­tion across queuing chan­nels, and trans­formers help turn a tightly coupled solu­tion into a loosely coupled one. The sender no longer has to depend on the re­ceiver's in­ternal data format nor on its loc­a­tion. It does not even have to pay at­ten­tion to whether or not the other com­puter is ready to accept re­quests. Re­mov­ing these de­pend­en­cies between the sys­tems makes the over­all solu­tion more tol­er­ant to change, the key be­ne­fit of loose coup­ling. The main draw­back of the loosely coupled ap­proach is the ad­di­tional com­plex­ity. This is no longer a 10-lines-of-code solu­tion! There­fore, we use a mes­sage-ori­ented mid­dle­ware in­fra­struc­ture that provides these ser­vices for us. This in­fra­struc­ture makes ex­chan­ging data in a loosely coupled way almost as easy as the ex­ample we star­ted with. The next sec­tion de­scribes the com­pon­ents that make up such a mid­dle­ware solu­tion.

松耦合是万能药吗？与企业架构中的其他事物一样，没有单一的最佳答案。松耦合提供了灵活性和可扩展性等重要优势，但它引入了更复杂的编程模型，并使设计、构建和调试解决方案变得更加困难。

Is loose coup­ling the pan­acea? Like everything else in en­ter­prise ar­chi­tec­ture, there is no single best answer. Loose coup­ling provides im­port­ant be­ne­fits such as flex­ib­il­ity and scalab­il­ity, but it in­tro­duces a more com­plex pro­gram­ming model and can make design­ing, build­ing, and de­bug­ging solu­tions more dif­fi­cult.

松耦合集成解决方案

A Loosely Coupled Integration Solution

为了通过集成解决方案连接两个系统，必须解决许多问题。这些功能构成了我们所说的中间件，即应用程序之间的粘合剂。

In order to con­nect two sys­tems via an in­teg­ra­tion solu­tion, a number of issues have to be re­solved. These func­tions make up what we call mid­dle­warethe glue that sits between ap­plic­a­tions.

某些数据总是必须从一个应用程序传输到下一个应用程序。该数据可能是需要复制的地址记录、对远程服务的调用或前往门户显示的 HTML 片段。无论有效负载如何，这段数据都需要被两端理解并且需要通过网络传输。两个元件提供了这一基本功能。我们需要一种可以将信息从一个应用程序转移到另一个应用程序的通信渠道。该通道可以由一系列 TCP/IP 连接、共享文件、共享数据库或从一台计算机传送到另一台计算机的软盘（臭名昭著的“sneakernet”）组成。在此频道内，我们放置一条消息对要集成的两个应用程序具有商定含义的数据片段。这条数据可以非常小，例如已更改的单个客户的电话号码，也可以非常大，例如所有客户及其关联地址的完整列表。

In­vari­ably, some data has to be trans­por­ted from one ap­plic­a­tion to the next. This data could be an ad­dress record that needs to be rep­lic­ated, a call to a remote ser­vice, or a snip­pet of HTML headed for a portal dis­play. Re­gard­less of the pay­load, this piece of data needs to be un­der­stood by both ends and needs to be trans­por­ted across a net­work. Two ele­ments provide this basic func­tion. We need a com­mu­nic­a­tions chan­nel that can move in­form­a­tion from one ap­plic­a­tion to the other. This chan­nel could con­sist of a series of TCP/IP con­nec­tions, a shared file, a shared data­base, or a floppy disk being car­ried from one com­puter to the next (the in­fam­ous "sneak­er­net"). Inside this chan­nel, we place a mes­sagea snip­pet of data that has an agreed-upon mean­ing to both ap­plic­a­tions that are to be in­teg­rated. This piece of data can be very small, such as the phone number of a single cus­tomer that has changed, or it can be very large, such as the com­plete list of all cus­tom­ers and their as­so­ci­ated ad­dresses.

基于消息的集成的基本要素

Basic Ele­ments of Mes­sage-Based In­teg­ra­tion

现在我们可以跨渠道发送消息，我们可以建立一种非常基本的集成形式。然而，我们承诺简单的集成是一个矛盾的说法，所以让我们看看缺少什么。我们提到集成解决方案通常对其所集成的应用程序具有有限的控制，例如应用程序使用的内部数据格式。例如，一种数据格式可能将客户姓名存储在两个字段中，称为FIRST_NAME和LAST_NAME ，而另一种系统可能使用称为Customer_Name的单个字段。同样，一个系统可能支持多个客户地址，而另一系统仅支持单个地址。由于应用程序的内部数据格式通常无法更改，因此中间件需要提供某种机制来将一个应用程序的数据格式转换为另一个应用程序的数据格式。我们称此步骤为翻译。

Now that we can send mes­sages across chan­nels, we can es­tab­lish a very basic form of in­teg­ra­tion. How­ever, we prom­ised that simple in­teg­ra­tion is an oxy­moron, so let's see what is miss­ing. We men­tioned that in­teg­ra­tion solu­tions often have lim­ited con­trol over the ap­plic­a­tions they are in­teg­rat­ing, such as the in­ternal data formats used by the ap­plic­a­tions. For ex­ample, one data format may store the cus­tomer name in two fields, called FIRST_­NAME and LAST_­NAME, while the other system may use a single field called Cus­tom­er­_­Name. Like­wise, one system may sup­port mul­tiple cus­tomer ad­dresses, while the other system sup­ports only a single ad­dress. Be­cause the in­ternal data format of an ap­plic­a­tion can often not be changed, the mid­dle­ware needs to provide some mech­an­ism to con­vert one ap­plic­a­tion's data format in the other's format. We call this step trans­la­tion.

到目前为止，我们可以将数据从一个系统发送到另一个系统，并适应数据格式的差异。如果我们集成两个以上的系统会发生什么？数据必须移动到哪里？我们可以期望每个应用程序为其通过通道发送的数据指定目标系统。例如，如果客户服务系统中的客户地址发生变化，我们可以让该系统负责将数据发送到存储客户地址副本的所有其他系统。随着系统数量的增加，这变得非常乏味，并且需要发送系统了解所有其他系统。每次添加新系统时，客户服务系统都必须调整以适应新环境。如果中间件可以负责将消息发送到正确的位置，事情就会容易得多。这是一个角色路由组件，例如消息代理。

So far, we can send data from one system to an­other and ac­com­mod­ate dif­fer­ences in data formats. What hap­pens if we in­teg­rate more than two sys­tems? Where does the data have to be moved? We could expect each ap­plic­a­tion to spe­cify the target system(s) for the data it is send­ing over the chan­nel. For ex­ample, if the cus­tomer ad­dress changes in the cus­tomer care system, we could make that system re­spons­ible for send­ing the data to all other sys­tems that store copies of the cus­tomer ad­dress. As the number of sys­tems in­creases, this be­comes very te­di­ous and re­quires the send­ing system to have know­ledge about all other sys­tems. Every time a new system is added, the cus­tomer care system would have to be ad­jus­ted to the new en­vir­on­ment. Things would be a lot easier if the mid­dle­ware could take care of send­ing mes­sages to the cor­rect places. This is the role of a rout­ing com­pon­ent, such as a mes­sage broker.

集成解决方案很快就会变得复杂，因为它们处理多种应用程序、数据格式、通道、路由和转换。所有这些元素可能分布在多个操作平台和地理位置。为了了解系统内部发生了什么，我们需要系统管理功能。该子系统监视数据流，确保所有应用程序和组件都启动并运行，并向中央位置报告错误情况。

In­teg­ra­tion solu­tions can quickly become com­plex be­cause they deal with mul­tiple ap­plic­a­tions, data formats, chan­nels, rout­ing, and trans­form­a­tion. All these ele­ments may be spread across mul­tiple op­er­at­ing plat­forms and geo­graphic loc­a­tions. In order to have any idea what is going on inside the system, we need a sys­tems man­age­ment func­tion. This sub­sys­tem mon­it­ors the flow of data, makes sure that all ap­plic­a­tions and com­pon­ents are up and run­ning, and re­ports error con­di­tions to a cent­ral loc­a­tion.

我们的集成解决方案现在已基本完成。我们可以将数据从一个系统转移到另一个系统，适应数据格式的差异，将数据路由到所需的系统，并监控解决方案的性能。到目前为止，我们假设应用程序将数据作为消息发送到通道。然而，大多数打包应用程序和遗留应用程序以及许多自定义应用程序都没有准备好参与集成解决方案。我们需要一个消息端点来将系统显式连接到集成解决方案。端点可以是一段特殊的代码，也可以是集成软件供应商提供的通道适配器。

Our in­teg­ra­tion solu­tion is now almost com­plete. We can move data from one system from an­other, ac­com­mod­ate dif­fer­ences in the data format, route the data to the re­quired sys­tems, and mon­itor the per­form­ance of the solu­tion. So far, we as­sumed that an ap­plic­a­tion sends data as a mes­sage to the chan­nel. How­ever, most pack­aged and legacy ap­plic­a­tions and many custom ap­plic­a­tions are not pre­pared to par­ti­cip­ate in an in­teg­ra­tion solu­tion. We need a mes­sage en­d­point to con­nect the system ex­pli­citly to the in­teg­ra­tion solu­tion. The en­d­point can be a spe­cial piece of code or a Chan­nel Ad­apter provided by an in­teg­ra­tion soft­ware vendor.

Widgets & Gadgets 'R Us：一个例子

Widgets & Gadgets 'R Us: An Example

了解基于消息的集成解决方案的最佳方法是通过一个具体示例。让我们考虑一下 Widgets & Gadgets 'R Us (WGRUS)，这是一家在线零售商，从制造商那里购买小部件和小工具并将其转售给客户。

The best way to un­der­stand mes­sage-based in­teg­ra­tion solu­tions is by walk­ing through a con­crete ex­ample. Let's con­sider Wid­gets & Gad­gets 'R Us (WGRUS), an online re­tailer that buys wid­gets and gad­gets from man­u­fac­tur­ers and re­sells them to cus­tom­ers.

WGRUS 生态系统

WGRUS Eco­sys­tem

对于此示例，我们假设解决方案需要支持以下要求。当然，为了简洁起见，我们对需求进行了一些简化，但尽管如此，此类需求在实际业务中还是经常出现。

For this ex­ample, we assume that the solu­tion needs to sup­port the fol­low­ing re­quire­ments. Nat­ur­ally, we sim­pli­fied the re­quire­ments a bit for sake of brev­ity, but nev­er­the­less these types of re­quire­ments occur fre­quently in real busi­nesses.

• 接受订单： 客户可以通过网络、电话或传真下订单。

• Take Orders: Cus­tom­ers can place orders via Web, phone, or fax.

• 处理订单： 处理订单涉及多个步骤，包括验证库存、运送货物以及向客户开具发票。

• Pro­cess Orders: Pro­cess­ing an order in­volves mul­tiple steps, in­clud­ing veri­fy­ing in­vent­ory, ship­ping the goods, and in­voicing the cus­tomer.

• 查看状态： 客户可以查看订单状态。

• Check Status: Cus­tom­ers can check the order status.

• 更改地址： 客户可以使用 Web 前端更改其帐单和送货地址。

• Change Ad­dress: Cus­tom­ers can use a Web front-end to change their billing and ship­ping ad­dress.

• 新目录： 供应商定期更新其目录。WGRUS 需要根据新目录更新其定价和供货情况。

• New Cata­log: The sup­pli­ers update their cata­log peri­od­ic­ally. WGRUS needs to update its pri­cing and avail­ab­il­ity based on the new cata­logs.

• 公告： 客户可以订阅 WGRUS 的选择性公告。

• An­nounce­ments: Cus­tom­ers can sub­scribe to se­lect­ive an­nounce­ments from WGRUS.

• 测试和监控： 操作人员需要能够监控所有单独的组件以及它们之间的消息流。

• Test­ing and Mon­it­or­ing: The op­er­a­tions staff needs to be able to mon­itor all in­di­vidual com­pon­ents and the mes­sage flow between them.

我们分别解决每个需求，并使用本书中介绍的模式语言描述解决方案的替代方案和权衡。我们将从简单的消息流架构开始，并随着我们解决日益复杂的需求而引入更复杂的概念，例如流程管理器。

We tackle each of these re­quire­ments sep­ar­ately and de­scribe the solu­tion al­tern­at­ives and trade-offs using the pat­tern lan­guage in­tro­duced in this book. We will start with a simple mes­sage flow ar­chi­tec­ture and in­tro­duce more com­plex con­cepts, such as a Pro­cess Man­ager, as we ad­dress in­creas­ingly com­plex re­quire­ments.

内部系统

In­ternal Sys­tems

与大多数集成场景一样，WGRUS 不是所谓的“绿地”实施，而是由各种打包和自定义应用程序组成的现有 IT 基础设施的集成。事实上，我们必须使用现有的应用程序，这常常使集成工作充满挑战。在我们的示例中，WGRUS 运行以下系统（见图）。

As in most in­teg­ra­tion scen­arios, WGRUS is not a so-called "green field" im­ple­ment­a­tion, but rather the in­teg­ra­tion of an ex­ist­ing IT in­fra­struc­ture com­prised of a vari­ety of pack­aged and custom ap­plic­a­tions. The fact that we have to work with ex­ist­ing ap­plic­a­tions often makes in­teg­ra­tion work chal­len­ging. In our ex­ample, WGRUS runs the fol­low­ing sys­tems (see figure).

WGRUS IT 基础设施

WGRUS IT In­fra­struc­ture

WGRUS 有四种不同的渠道与客户互动。客户可以访问公司网站、致电呼叫中心的客户服务代表或通过传真提交订单。客户还可以通过电子邮件接收通知。

WGRUS has four dif­fer­ent chan­nels to in­ter­act with cus­tom­ers. Cus­tom­ers can visit the com­pany Web site, call the cus­tomer ser­vice rep­res­ent­at­ive at the call center, or submit orders via fax. Cus­tom­ers can also re­ceive no­ti­fic­a­tions via e-mail.

WGRUS 的内部系统由会计系统（还包括计费功能）和运输系统（计算运输费用并与运输公司交互）组成。由于历史原因，WGRUS 有两个库存和目录系统。WGRUS 过去只销售小部件，但后来收购了另一家销售小部件的零售商。

WGRUS's in­ternal sys­tems are com­prised of the ac­count­ing system, which also in­cludes billing func­tions, and the ship­ping system that com­putes ship­ping charges and in­ter­acts with the ship­ping com­pan­ies. For his­toric reas­ons, WGRUS has two in­vent­ory and cata­log sys­tems. WGRUS used to sell only wid­gets but ac­quired an­other re­tailer that sells gad­gets.

接受订单

Taking Orders

我们要实现的第一个功能是接受订单。接受订单是一件好事，因为订单带来收入。然而，目前下订单是一个繁琐的手工过程，因此每个订单产生的成本很高。

The first func­tion we want to im­ple­ment is taking orders. Taking orders is a good thing be­cause orders bring rev­enue. How­ever, pla­cing orders is cur­rently a te­di­ous manual pro­cess, so the cost in­curred with each order is high.

简化订单处理的第一步是统一接单。客户可以通过以下三种渠道之一下订单：网站、呼叫中心或传真。不幸的是，每个系统都基于不同的技术，并以不同的数据格式存储传入的订单。呼叫中心系统是一个打包的应用程序，而网站是一个定制的J2EE应用程序。入站传真系统需要将数据手动输入到小型 Microsoft Access 应用程序中。我们希望平等对待所有订单，无论其来源如何。例如，客户应该能够通过呼叫中心下订单并在网站上检查订单状态。

The first step to stream­lin­ing order pro­cess­ing is to unify taking orders. A cus­tomer can place orders over one of three chan­nels: Web site, call center, or fax. Un­for­tu­nately, each system is based on a dif­fer­ent tech­no­logy and stores in­com­ing orders in a dif­fer­ent data format. The call center system is a pack­aged ap­plic­a­tion, while the Web site is a custom J2EE ap­plic­a­tion. The in­bound fax system re­quires manual data entry into a small Mi­crosoft Access ap­plic­a­tion. We want to treat all orders equally, re­gard­less of their source. For ex­ample, a cus­tomer should be able to place an order via the call center and check the order status on the Web site.

由于下订单是一个连接多个系统的异步过程，因此我们决定实施面向消息的中间件解决方案来简化订单输入流程。打包的呼叫中心应用程序在开发时并未考虑集成，因此我们必须使用通道适配器将其连接到消息传递系统。通道适配器是一个组件，可以附加到应用程序并在应用程序内部发生事件时将消息发布到消息通道。使用一些通道适配器，应用程序甚至可能不知道适配器的存在。例如，数据库适配器可以向特定表添加触发器，以便应用程序每次插入一行数据时，都会向消息通道发送一条消息。 通道适配器还可以以相反的方向工作，从消息通道消费消息并触发应用程序内的操作作为响应。

Be­cause pla­cing an order is an asyn­chron­ous pro­cess that con­nects many sys­tems, we decide to im­ple­ment a mes­sage-ori­ented mid­dle­ware solu­tion to stream­line the order entry pro­cess. The pack­aged call center ap­plic­a­tion was not de­ve­loped with in­teg­ra­tion in mind so that we have to con­nect it to the mes­saging system using a Chan­nel Ad­apter. A Chan­nel Ad­apter is a com­pon­ent that can attach to an ap­plic­a­tion and pub­lish mes­sages to a Mes­sage Chan­nel whenever an event occurs inside the ap­plic­a­tion. With some Chan­nel Ad­apters, the ap­plic­a­tion may not even be aware of the pres­ence of the ad­apter. For ex­ample, a data­base ad­apter may add trig­gers to spe­cific tables so that every time the ap­plic­a­tion in­serts a row of data, a mes­sage is sent to the Mes­sage Chan­nel. Chan­nel Ad­apters can also work in the op­pos­ite dir­ec­tion, con­sum­ing mes­sages off a Mes­sage Chan­nel and trig­ger­ing an action inside the ap­plic­a­tion in re­sponse.

我们对入站传真应用程序使用相同的方法，将通道适配器连接到应用程序数据库。由于 Web 应用程序是自定义构建的，因此我们在应用程序内部实现消息端点代码。我们使用消息传递网关将应用程序代码与消息传递特定的代码隔离。

We use the same ap­proach for the in­bound fax ap­plic­a­tion, con­nect­ing the Chan­nel Ad­apter to the ap­plic­a­tion data­base. Be­cause the Web ap­plic­a­tion is custom built, we im­ple­ment the Mes­sage En­d­point code inside the ap­plic­a­tion. We use a Mes­saging Gate­way to isol­ate the ap­plic­a­tion code from the mes­saging-spe­cific code.

从三个不同渠道接受订单

Taking Orders from Three Dif­fer­ent Chan­nels

由于每个系统对传入订单使用不同的数据格式，因此我们使用三个消息转换器将不同的数据格式转换为遵循规范数据模型的通用新订单消息。规范数据模型定义了独立于任何特定应用程序的消息格式，以便所有应用程序都可以采用这种通用格式相互通信。如果应用程序的内部格式发生变化，则只有受影响的应用程序和公共消息通道之间的消息转换器必须更改，而所有其他应用程序和消息转换器保持不受影响。用一个规范数据模型意味着我们处理两种类型的消息：规范（公共）消息和特定于应用程序的（私有）消息。应用程序特定的消息不应由该应用程序和关联的消息转换器以外的任何组件使用。 为了强化这一策略，我们以应用程序开头来命名特定于应用程序的消息通道：例如WEB_NEW_ORDER 。相反，携带规范消息的通道以消息的意图命名，没有任何前缀：例如NEW_ORDER。

Be­cause each system uses a dif­fer­ent data format for the in­com­ing orders, we use three Mes­sage Trans­lat­ors to con­vert the dif­fer­ent data formats into a common New Order mes­sage that fol­lows a Ca­non­ical Data Model. A Ca­non­ical Data Model defines mes­sage formats that are in­de­pend­ent from any spe­cific ap­plic­a­tion so that all ap­plic­a­tions can com­mu­nic­ate with each other in this common format. If the in­ternal format of an ap­plic­a­tion changes, only the Mes­sage Trans­lator between the af­fected ap­plic­a­tion and the common Mes­sage Chan­nel has to change, while all other ap­plic­a­tions and Mes­sage Trans­lat­ors remain un­af­fected. Using a Ca­non­ical Data Model means that we deal with two types of mes­sages: ca­non­ical (public) mes­sages and ap­plic­a­tion-spe­cific (private) mes­sages. Ap­plic­a­tion-spe­cific mes­sages should not be con­sumed by any com­pon­ent other than that ap­plic­a­tion and the as­so­ci­ated Mes­sage Trans­lator. To re­in­force this policy, we name ap­plic­a­tion-spe­cific Mes­sage Chan­nels start­ing with the name of the ap­plic­a­tion: for ex­ample, WEB_NEW_ORDER. In con­trast, chan­nels car­ry­ing ca­non­ical mes­sages are named after the intent of the mes­sage without any prefix: for ex­ample, NEW_ORDER.

我们通过点对点通道将每个通道适配器连接到消息转换器，因为我们希望确保每个订单消息仅被消耗一次。如果我们将转换逻辑编程到消息传递网关中，我们就可以在不使用 Web 界面消息转换器的情况下完成任务。 然而，手动编码转换函数可能很乏味且容易出错，我们更喜欢使用一致的方法。附加的消息转换器还允许我们保护新订单流免受 Web 界面数据格式的微小变化的影响。所有消息翻译器发布到相同的NEW_ORDER 点对点通道，以便可以通过该通道处理订单，而无需考虑订单的来源。

We con­nect each Chan­nel Ad­apter to the Mes­sage Trans­lator via a Point-to-Point Chan­nel be­cause we want to be sure that each order mes­sage is con­sumed only once. We could get away without using a Mes­sage Trans­lator for the Web in­ter­face if we pro­grammed the trans­form­a­tion logic into the Mes­saging Gate­way. How­ever, hand-coding trans­form­a­tion func­tions can be te­di­ous and error-prone, and we prefer to use a con­sist­ent ap­proach. The ad­di­tional Mes­sage Trans­lator also allows us to shield the New Order flow from minor changes in the Web in­ter­face data format. All Mes­sage Trans­lat­ors pub­lish to the same NEW_ORDER Point-to-Point Chan­nel so that orders can be pro­cessed off this chan­nel without regard to the order's origin.

NEW_ORDER消息通道是所谓的数据类型通道，因为它仅承载一种 类型的消息：新订单。这使得消息消费者很容易知道期望的消息类型。新订单消息本身被设计为文档消息。该消息的目的不是指示接收者采取特定操作，而是将文档传递给任何感兴趣的接收者，后者可以自由决定如何处理该文档。

The NEW_ORDER Mes­sage Chan­nel is a so-called Data­type Chan­nel be­cause it car­ries mes­sages of only one type: new orders. This makes it easy for mes­sage con­sumers to know what type of mes­sage to expect. The New Order mes­sage itself is de­signed as a Doc­u­ment Mes­sage. The intent of the mes­sage is not to in­struct the re­ceiver to take a spe­cific action, but rather to pass a doc­u­ment to any in­ter­ested re­cip­i­ent, who is free to decide how to pro­cess the doc­u­ment.

处理订单

Pro­cess­ing Orders

现在我们有了独立于消息源的一致订单消息，我们准备好处理订单了。为了履行订单，我们需要完成以下步骤：

Now that we have a con­sist­ent order mes­sage that is in­de­pend­ent from the mes­sage source, we are ready to pro­cess orders. To ful­fill an order, we need to com­plete the fol­low­ing steps:

• 验证客户的信用状况。 如果客户有未付账单，我们要拒绝新订单。

• Verify the cus­tomer's credit stand­ing. If the cus­tomer has out­stand­ing bills, we want to reject the new order.

• 核实库存。 我们无法履行没有库存的商品订单。

• Verify in­vent­ory. We can't ful­fill orders for items that are not in stock.

• 如果客户信誉良好并且我们有库存，我们希望发货并向客户开具账单。

• If the cus­tomer is in good stand­ing and we have in­vent­ory, we want to ship the goods and bill the cus­tomer.

我们可以使用统一建模语言 (UML) 活动图来表达这一系列事件。活动图具有相对简单的语义，是描述包含并行活动的流程的好工具。符号非常简单；连续的活动通过简单的箭头连接起来。并行活动通过代表分叉和连接操作的粗黑条连接。分叉操作会导致所有连接的活动同时启动，而连接操作仅在所有传入活动完成后才继续。

We can ex­press this se­quence of events using a Uni­fied Mod­el­ing Lan­guage (UML) activ­ity dia­gram. Activ­ity dia­grams have re­l­at­ively simple se­mantics and are a good tool to depict pro­cesses that in­clude par­al­lel activ­it­ies. The nota­tion is very simple; se­quen­tial activ­it­ies are con­nec­ted by simple arrows. Par­al­lel activ­it­ies are con­nec­ted by a thick black bar rep­res­ent­ing fork and join ac­tions. A fork action causes all con­nec­ted activ­it­ies to start sim­ul­tan­eously, while the join action con­tin­ues only after all in­com­ing activ­it­ies have been com­pleted.

我们的活动图（见图）旨在并行执行“检查库存”任务和“验证客户信誉”任务。连接栏会等到两个活动都完成后才允许下一个活动开始。下一个活动验证这两个步骤的结果：我们是否有库存，客户信誉良好吗？如果两个条件都满足，则流程将继续履行订单。否则，我们将过渡到异常处理活动。例如，我们可能会打电话提醒客户支付最后一张发票或发送电子邮件让他或她知道订单将被延迟。因为本书重点关注面向消息的集成的设计方面而不是工作流建模，我们暂时将异常处理过程的细节放在一边。有关工作流架构和工作流建模的非常好的讨论，请参阅[雷曼]和[夏普]。

Our activ­ity dia­gram (see figure) is de­signed to ex­ecute the Check In­vent­ory task and the Val­id­ate Cus­tomer Stand­ing task in par­al­lel. The join bar waits until both activ­it­ies are com­pleted before it allows the next activ­ity to start. The next activ­ity veri­fies the res­ults of both steps: Do we have in­vent­ory, and is the cus­tomer in good stand­ing? If both con­di­tions are ful­filled, the pro­cess goes on to ful­fill the order. Oth­er­wise, we trans­ition to an ex­cep­tion-hand­ling activ­ity. For ex­ample, we may call to remind the cus­tomer to pay the last in­voice or send an e-mail let­ting him or her know that the order will be delayed. Be­cause this book fo­cuses on the design as­pects of mes­sage-ori­ented in­teg­ra­tion rather than on work­flow mod­el­ing, we leave the de­tails of the ex­cep­tion-hand­ling pro­cess aside for now. For a very good dis­cus­sions of work­flow ar­chi­tec­ture and work­flow mod­el­ing, refer to [Leyman] and [Sharp].

订单处理活动图

Activ­ity Dia­gram for Order Pro­cess­ing

事实证明，活动图中的活动相对较好地映射到 WGRUS IT 部门的系统。会计系统验证客户的信用状况，库存系统检查库存，运输系统启动货物的实际运输。会计系统还充当计费系统并发送发票。我们可以看到，订单的处理是一个典型的分布式业务流程的实现。

It turns out that the activ­it­ies in the activ­ity dia­gram map re­l­at­ively nicely to the sys­tems in WGRUS's IT de­part­ment. The ac­count­ing system veri­fies the cus­tomer's credit stand­ing, the in­vent­ory sys­tems check the in­vent­ory, and the ship­ping system ini­ti­ates the phys­ical ship­ping of goods. The ac­count­ing system also acts as the billing system and sends in­voices. We can see that the pro­cess­ing of orders is a typ­ical im­ple­ment­a­tion of a dis­trib­uted busi­ness pro­cess.

为了将逻辑活动图转换为集成设计，我们可以使用发布-订阅通道来实现 fork 操作，并使用聚合器来实现 join 操作。发布-订阅通道向所有活跃消费者发送消息；聚合器接收多个传入消息并将它们组合成单个传出消息（见图）。

To con­vert the lo­gical activ­ity dia­gram into an in­teg­ra­tion design, we can use a Pub­lish-Sub­scribe Chan­nel to im­ple­ment the fork action and an Ag­greg­ator to im­ple­ment the join action. A Pub­lish-Sub­scribe Chan­nel sends a mes­sage to all active con­sumers; an Ag­greg­ator re­ceives mul­tiple in­com­ing mes­sages and com­bines them into a single, out­go­ing mes­sage (see figure).

使用异步消息传递的订单处理实现

Order Pro­cess­ing Im­ple­ment­a­tion Using Asyn­chron­ous Mes­saging

在我们的示例中，发布-订阅通道将新订单消息发送到会计系统和库存系统。聚合器组合来自两个系统的结果消息并将组合的消息传递到基于内容的路由器。基于内容的路由器是一个组件，它使用消息并将其未经修改地发布到基于路由器内部编码的规则选择的其他通道。基于内容的路由器相当于UML活动图中的分支。在这种情况下，如果库存检查和信用检查都是肯定的，则基于内容的路由器将消息转发到VALIDATED_ORDER频道。该通道是发布-订阅通道，因此经过验证的订单会同时到达运输和计费系统。如果客户信誉不佳或者我们手头没有库存，基于内容的路由器会将消息转发到INVALID_ORDER通道。异常处理流程（图中未显示）侦听此通道上的消息并通知客户订单被拒绝。

In our ex­ample, the Pub­lish-Sub­scribe Chan­nel sends the New Order mes­sage to both the ac­count­ing system and the in­vent­ory system. The Ag­greg­ator com­bines the result mes­sages from both sys­tems and passes the com­bined mes­sage to a Con­tent-Based Router. A Con­tent-Based Router is a com­pon­ent that con­sumes a mes­sage and pub­lishes it, un­mod­i­fied, to a choice of other chan­nels based on rules coded inside the router. The Con­tent-Based Router is equi­val­ent to the branch in a UML activ­ity dia­gram. In this case, if both the in­vent­ory check and the credit check have been af­firm­at­ive, the Con­tent-Based Router for­wards the mes­sage to the VAL­ID­ATED_ORDER chan­nel. This chan­nel is a Pub­lish-Sub­scribe Chan­nel, so the val­id­ated order reaches both the ship­ping and the billing sys­tems. If the cus­tomer is not in good stand­ing or we have no in­vent­ory on hand, Con­tent-Based Router for­wards the mes­sage to the IN­VAL­ID_ORDER chan­nel. An ex­cep­tion-hand­ling pro­cess (not shown in the figure) listens to mes­sages on this chan­nel and no­ti­fies the cus­tomer of the re­jec­ted order.

现在我们已经建立了整体的消息流，我们需要仔细研究一下库存函数。正如我们在需求部分中了解到的，WGRUS 有两种库存系统：一种用于小部件，一种用于小工具。因此，我们必须将库存请求路由到正确的系统。因为我们希望对其他系统隐藏库存系统的特殊性，所以我们插入另一个基于内容的路由器，该路由器根据订购的商品类型将消息路由到正确的库存系统（见图）。例如，所有商品编号以 W 开头的传入消息都会路由到小部件库存系统，所有商品编号以 G 开头的订单都会路由到小工具库存系统。

Now that we have es­tab­lished the over­all mes­sage flow, we need to have a closer look at the in­vent­ory func­tion. As we learned in the re­quire­ments sec­tion, WGRUS has two in­vent­ory sys­tems: one for wid­gets and one for gad­gets. As a result, we have to route the re­quest for in­vent­ory to the cor­rect system. Be­cause we want to hide the pe­cu­li­ar­it­ies of the in­vent­ory sys­tems from the other sys­tems, we insert an­other Con­tent-Based Router that routes the mes­sage to the cor­rect in­vent­ory system based on the type of item ordered (see figure). For ex­ample, all in­com­ing mes­sages with an item number start­ing with W are routed to the widget in­vent­ory system, and all orders with an item number start­ing with G are routed to the gadget in­vent­ory system.

路由库存请求

Rout­ing the In­vent­ory Re­quest

请注意，基于内容的路由器和库存系统之间的点对点通道上的消息意图与之前的通道不同。这些通道包含命令消息，指示系统执行指定命令的消息，在本例中验证项目的库存。

Note that the intent of mes­sages on the Point-to-Point Chan­nels between the Con­tent-Based Router and the in­vent­ory sys­tems is dif­fer­ent from the pre­vi­ous chan­nel. These chan­nels con­tain Com­mand Mes­sages, mes­sages that in­struct the system to ex­ecute the spe­cified com­mand, in this case veri­fy­ing the in­vent­ory of an item.

由于小部件库存系统和小工具库存系统使用不同的内部数据格式，因此我们再次插入消息转换器以将规范的新订单消息格式转换为系统特定的格式。

Be­cause the widget in­vent­ory system and the gadget in­vent­ory system use dif­fer­ent in­ternal data formats, we again insert Mes­sage Trans­lat­ors to con­vert from the ca­non­ical New Order mes­sage format to a system-spe­cific format.

如果订单商品既不以 W 也不以 G 开头，会发生什么情况？基于内容的路由器将消息路由到INVALID_ORDER通道，以便可以通过通知客户等方式相应地处理无效订单。该通道是无效消息通道的典型示例。 它强调了这样一个事实：消息的含义会根据其所在的渠道而变化。NEW_ORDER通道和INVALID_ORDER通道都传输相同类型的消息，但在一种情况下正在处理新订单，而在另一种情况下订单被视为无效。

What hap­pens if the order item starts neither with W nor G? The Con­tent-Based Router routes the mes­sage to the IN­VAL­ID_ORDER chan­nel so that the in­valid order can be pro­cessed ac­cord­ingly, by no­ti­fy­ing the cus­tomer, for ex­ample. This chan­nel is a typ­ical ex­ample of an In­valid Mes­sage Chan­nel. It high­lights the fact that the mean­ing of a mes­sage changes de­pend­ing on what chan­nel it is on. Both the NEW_ORDER chan­nel and the IN­VAL­ID_ORDER chan­nel trans­port the same type of mes­sage, but in one case a new order is being pro­cessed, while in the other case the order is deemed in­valid.

到目前为止，我们假设每个订单只包含一个商品。这对我们的客户来说非常不方便，因为他们必须为每件商品下新订单。此外，我们最终会向同一客户运送多个订单，并产生不必要的运输费用。但是，如果我们允许一个订单中包含多个商品，那么哪个库存系统应该验证该订单的库存？我们可以使用发布-订阅通道将订单发送到每个库存系统，以挑选它可以处理的项目。但是无效的物品会怎样呢？我们如何注意到库存系统都没有处理该物品？我们想要维护基于内容的路由器的中央控制给了我们，但我们需要能够单独路由每个订单项目。

So far, we have as­sumed that each order con­tains only a single item. This would be pretty in­con­veni­ent for our cus­tom­ers be­cause they would have to place a new order for each item. Also, we would end up ship­ping mul­tiple orders to the same cus­tomer and incur un­ne­ces­sary ship­ping costs. How­ever, if we allow mul­tiple items inside an order, which in­vent­ory system should verify the in­vent­ory for this order? We could use a Pub­lish-Sub­scribe Chan­nel to send the order to each in­vent­ory system to pick out the items that it can pro­cess. But what would then happen to in­valid items? How would we notice that neither in­vent­ory system pro­cessed the item? We want to main­tain the cent­ral con­trol the Con­tent-Based Router gives us, but we need to be able to route each order item in­di­vidu­ally.

因此，我们插入一个Splitter ，该组件将单个消息分成多个单独的消息。在我们的例子中，拆分器将单个订单消息拆分为多个订单项目消息。然后，可以像以前一样使用基于内容的路由器将每个订单项目消息路由到正确的库存系统；见下图。

There­fore, we insert a Split­ter, a com­pon­ent that breaks a single mes­sage into mul­tiple in­di­vidual mes­sages. In our case, the Split­ter splits a single Order mes­sage into mul­tiple Order Item mes­sages. Each Order Item mes­sage can then be routed to the cor­rect in­vent­ory system using a Con­tent-Based Router as before; see the fol­low­ing figure.

单独处理订单项目

Pro­cess­ing Order Items In­di­vidu­ally

当然，当所有物品的库存都得到验证后，我们需要将消息重新组合成一条消息。我们已经了解到，可以将多个消息组合成单个消息的组件是聚合器。使用 Splitter和Aggregator ，我们可以在逻辑上将单个订单项的消息流与完整订单的消息流分开。

Nat­ur­ally, when the in­vent­ory for all items has been veri­fied, we need to re­com­bine the mes­sages into a single mes­sage. We already learned that the com­pon­ent that can com­bine mul­tiple mes­sages into a single mes­sage is the Ag­greg­ator. Using both a Split­ter and an Ag­greg­ator, we can lo­gic­ally sep­ar­ate the mes­sage flow for in­di­vidual order items from the flow for a com­plete order.

在设计聚合器时，我们必须做出三个关键决定：

When design­ing an Ag­greg­ator, we have to make three key de­cisions:

• 哪些消息属于同一组（相关性）？

• Which mes­sages belong to­gether (cor­rel­a­tion)?

• 我们如何确定所有消息都已收到（完整性条件）？

• How do we de­term­ine that all mes­sages are re­ceived (the com­plete­ness con­di­tion)?

• 我们如何将各个消息组合成一个结果消息（聚合算法）？

• How do we com­bine the in­di­vidual mes­sages into one result mes­sage (the ag­greg­a­tion al­gorithm)?

让我们一一解决这些问题。我们无法通过客户 ID 关联订单项目，因为客户可能会在短时间内连续下多个订单。因此，我们需要为每个订单分配一个唯一的订单ID。我们通过将内容丰富器插入到接受订单的解决方案部分来实现此目的（见图）。内容丰富器是一个将缺失的数据项添加到传入消息中的组件。在我们的例子中，内容丰富器向消息添加了唯一的订单 ID。

Let's tackle these issues one by one. We can't cor­rel­ate order items by the cus­tomer ID, be­cause a cus­tomer may place mul­tiple orders in short suc­ces­sion. There­fore, we need a unique order ID for each order. We ac­com­plish this by in­sert­ing a Con­tent En­richer into the part of the solu­tion that takes orders (see figure). A Con­tent En­richer is a com­pon­ent that adds miss­ing data items to an in­com­ing mes­sage. In our case, the Con­tent En­richer adds a unique order ID to the mes­sage.

通过 Enricher 接受订单

Taking Orders with En­richer

现在我们有了一个订单 ID 来关联订单项消息，我们需要定义订单项聚合器的完整性条件和聚合算法。因为我们将所有消息（包括无效商品）路由到聚合器，所以聚合器可以简单地使用订单中的商品数量（订单消息中的字段之一）进行计数，直到所有订单商品到达为止。聚合算法同样简单。聚合器将所有订单项消息连接回单个订单消息并将其发布到VALIDATED_ORDER 通道。

Now that we have an order ID to cor­rel­ate Order Item mes­sages, we need to define the com­plete­ness con­di­tion and the ag­greg­a­tion al­gorithm for the Order Item Ag­greg­ator. Be­cause we route all mes­sages, in­clud­ing in­valid items, to the Ag­greg­ator, the Ag­greg­ator can simply use the number of items in the order (one of the fields in the Order mes­sage) to count until all order items arrive. The ag­greg­a­tion al­gorithm is sim­il­arly simple. The Ag­greg­ator con­cat­en­ates all Order Item mes­sages back into a single Order mes­sage and pub­lishes it to the VAL­ID­ATED_ORDER chan­nel.

Splitter、Message Router和Aggregator的组合相当常见。我们将其称为组合消息处理器。为了简化该图，我们将组合消息处理器的符号插入到原始消息流图中：

The com­bin­a­tion of a Split­ter, a Mes­sage Router, and an Ag­greg­ator is fairly common. We refer to it as a Com­posed Mes­sage Pro­cessor. To sim­plify the figure, we insert the symbol for a Com­posed Mes­sage Pro­cessor into the ori­ginal mes­sage flow dia­gram:

修订后的订单流程实施

Re­vised Order Pro­cess Im­ple­ment­a­tion

检查状态

Check­ing Status

尽管通过消息通道连接系统，但履行订单可能需要一些时间。例如，我们可能缺少某种商品，并且库存系统可能会保留库存检查消息，直到新商品到达为止。这是异步消息传递的优点之一：通信被设计为按照组件的速度进行。当库存系统保留该消息时，会计系统仍然可以验证客户的信用状况。完成这两个步骤后，聚合器将发布“已验证订单”消息以启动发货和开具发票。

Des­pite con­nect­ing the sys­tems via Mes­sage Chan­nels, ful­filling an order can take some amount of time. For ex­ample, we may be out of a cer­tain item and the in­vent­ory system may be hold­ing the In­vent­ory Check mes­sage until new items arrive. This is one of the ad­vant­ages of asyn­chron­ous mes­saging: the com­mu­nic­a­tion is de­signed to happen at the pace of the com­pon­ents. While the in­vent­ory system is hold­ing the mes­sage, the ac­count­ing system can still verify the cus­tomer's credit stand­ing. Once both steps are com­pleted, the Ag­greg­ator pub­lishes the Val­id­ated Order mes­sage to ini­ti­ate ship­ment and in­voicing.

长期运行的业务流程还意味着客户和经理都可能想知道特定订单的状态。例如，如果某些商品缺货，客户可能决定仅处理有库存的商品。或者，如果客户还没有收到货物，我们可以告诉他或她货物正在运送途中（包括运输公司的追踪号码）或仓库内部出现延误，这会很有用。

A long-run­ning busi­ness pro­cess also means that both cus­tom­ers and man­agers are likely to want to know the status of a spe­cific order. For ex­ample, if cer­tain items are out of in­vent­ory, the cus­tomer may decide to pro­cess just those items that are in stock. Or, if the cus­tomer has not re­ceived the goods, it is useful if we can tell him or her that the goods are on their way (in­clud­ing the ship­ping com­pany's track­ing number) or that there is an in­ternal delay in the ware­house.

使用当前设计跟踪订单状态并不那么容易。相关消息流经多个系统。为了确定步骤序列中订单的状态，我们必须知道与该订单相关的“最后”消息。发布-订阅通道的优点之一是我们可以在不干扰消息流的情况下添加其他订阅者。我们可以使用此属性来侦听新的和经过验证的订单并将它们存储在Message Store中。然后，我们可以查询消息存储数据库以获取订单状态（见图）：

Track­ing the status of an order with the cur­rent design is not so easy. Re­lated mes­sages flow through mul­tiple sys­tems. To as­cer­tain the status of the order in the se­quence of steps, we would have to know the "last" mes­sage re­lated to this order. One of the ad­vant­ages of a Pub­lish-Sub­scribe Chan­nel is that we can add ad­di­tional sub­scribers without dis­turb­ing the flow of mes­sages. We can use this prop­erty to listen in to new and val­id­ated orders and store them in a Mes­sage Store. We could then query the Mes­sage Store data­base for the status of an order (see figure):

添加消息存储以跟踪订单状态

Adding a Mes­sage Store to Track Order Status

在我们使用点对点通道的情况下，我们不能简单地将订阅者添加到通道中，因为点对点通道确保每条消息仅由单个订阅者消费。但是，我们可以插入一个Wire Tap，这是一个简单的组件，它使用一个通道的消息并将其发布到两个通道。然后我们可以使用第二个通道将消息发送到消息存储；见图。

In situ­ations where we use a Point-Point Chan­nel, we cannot simply add a sub­scriber to the chan­nel, be­cause a Point-to-Point Chan­nel en­sures that each mes­sage is only con­sumed by a single sub­scriber. How­ever, we can insert a Wire Tap, a simple com­pon­ent that con­sumes a mes­sage off one chan­nel and pub­lishes it to two chan­nels. We can then use the second chan­nel to send mes­sages to the Mes­sage Store; see figure.

使用窃听器跟踪消息

Track­ing Mes­sages with a Wire Tap

将消息数据存储在中央数据库中还有另一个显着的优点。在最初的设计中，每条消息都必须携带无关的数据，以便继续处理该消息。例如，验证客户信誉消息可能必须传输各种客户数据，即使它只需要客户 ID。此附加数据是必要的，以便生成的消息仍然包含原始订单消息中的所有数据。在消息流开始时将 New Order 消息存储在Message Store中的优点是所有后续组件都可以引用Message Store用于重要的消息数据，而无需所有中间步骤携带数据。我们将这样的功能称为“索赔检查消息”，可以“签入”数据以供以后检索。这种方法的缺点是访问中央数据存储不如通过异步消息通道发送消息可靠。

Stor­ing mes­sage data in a cent­ral data­base has an­other sig­ni­fic­ant ad­vant­age. In the ori­ginal design, each mes­sage had to carry ex­traneous data in order to con­tinue pro­cess­ing the mes­sage down the line. For ex­ample, the Val­id­ate Cus­tomer Stand­ing mes­sage may have had to trans­port all sorts of cus­tomer data even though it re­quired only the cus­tomer ID. This ad­di­tional data is ne­ces­sary so that the res­ult­ing mes­sage still con­tains all data from the ori­ginal order mes­sage. Stor­ing the New Order mes­sage in a Mes­sage Store at the be­gin­ning of the mes­sage flow has the ad­vant­age that all sub­se­quent com­pon­ents can refer to the Mes­sage Store for im­port­ant mes­sage data without all in­ter­me­di­ate steps having to carry the data along. We refer to such a func­tion as Claim Check mes­sages can "check in" data for later re­trieval. The down­side of this ap­proach is that ac­cess­ing a cent­ral data store is not as re­li­able as send­ing mes­sages across asyn­chron­ous Mes­sage Chan­nels.

现在，消息存储负责维护与新消息相关的数据以及消息在流程中的进度。这些数据为我们提供了足够的信息，可以使用消息存储来确定流程中接下来所需的步骤，而不是使用固定的消息通道连接组件。例如，如果数据库包含来自库存系统和计费系统的回复消息，我们可以得出结论，订单已经过验证，并且可以向运输和计费系统发送消息。我们可以在消息存储中直接完成此决定，而不是在单独的聚合器组件中做出此决定。实际上，我们正在将消息存储转变为流程管理器。

Now, the Mes­sage Store is re­spons­ible for main­tain­ing data re­lated to the new mes­sage as well as the pro­gress of the mes­sage within the pro­cess. This data gives us enough in­form­a­tion to use the Mes­sage Store to de­term­ine the next re­quired steps in the pro­cess rather than con­nect­ing com­pon­ents with fixed Mes­sage Chan­nels. For ex­ample, if the data­base con­tains reply mes­sages from both the in­vent­ory sys­tems and the billing system, we can con­clude that the order has been val­id­ated and can send a mes­sage to the ship­ping and billing sys­tems. In­stead of making this de­cision in a sep­ar­ate Ag­greg­ator com­pon­ent, we can do it right in the Mes­sage Store. Ef­fect­ively, we are turn­ing the Mes­sage Store into a Pro­cess Man­ager.

流程管理器是管理系统中消息流的核心组件。流程管理器提供两个主要功能：

A Pro­cess Man­ager is a cent­ral com­pon­ent that man­ages the flow of mes­sages through the system. The Pro­cess Man­ager provides two main func­tions:

• 在消息之间存储数据（在“流程实例”内）

• Stor­ing data between mes­sages (inside a "pro­cess in­stance")

• 跟踪进度并确定下一步（通过使用“流程模板”）

• Keep­ing track of pro­gress and de­term­in­ing the next step (by using a "pro­cess tem­plate")

使用流程管理器处理订单

Pro­cess­ing Orders with a Pro­cess Man­ager

这种架构将各个系统（例如，库存系统）转变为共享业务功能，其他组件可以将其作为服务进行访问，从而提高重用性并简化维护。这些服务可以通过消息流连接在一起（例如，使用组合消息处理器检查每个订单项的库存状态）或通过流程。使用流程管理器使得更改消息流比我们以前的方法容易得多。

This ar­chi­tec­ture turns the in­di­vidual sys­tems (e.g., the in­vent­ory sys­tems) into shared busi­ness func­tions that can be ac­cessed by other com­pon­ents as ser­vices, thus in­creas­ing reuse and sim­pli­fy­ing main­ten­ance. The ser­vices can be wired to­gether via a mes­sage flow (for ex­ample, using a Com­posed Mes­sage Pro­cessor to check in­vent­ory status for each order item) or or­ches­trated via a Pro­cess Man­ager. Using a Pro­cess Man­ager makes chan­ging the flow of mes­sages much easier than our pre­vi­ous ap­proach.

新的架构将所有服务公开给公共服务总线，以便可以从任何其他组件调用它们。我们可以通过添加从中央服务注册表查找（“发现”）服务的设施，将 WGRUS IT 基础架构转变为 SOA。为了参与此 SOA，每个服务都必须提供附加功能。例如，每个服务都必须公开一个描述该服务提供的功能的接口契约。每个请求-答复服务还需要支持返回地址的概念。 退货地址允许调用者（服务使用者）指定服务应发送回复消息的通道。这对于允许在不同上下文中重用服务非常重要，每个上下文可能需要自己的回复消息通道。

The new ar­chi­tec­ture ex­poses all ser­vices to a common ser­vices bus so that they can be in­voked from any other com­pon­ent. We could turn the WGRUS IT in­fra­struc­ture into an SOA by adding fa­cil­it­ies to look up ("dis­cover") a ser­vice from a cent­ral ser­vice re­gistry. In order to par­ti­cip­ate in this SOA, each ser­vice would have to provide ad­di­tional func­tions. For ex­ample, each ser­vice would have to expose an in­ter­face con­tract that de­scribes the func­tions provided by the ser­vice. Each re­quest-reply ser­vice also needs to sup­port the concept of a Return Ad­dress. A Return Ad­dress allows the caller (the ser­vice con­sumer) to spe­cify the chan­nel where the ser­vice should send the reply mes­sage. This is im­port­ant to allow the ser­vice to be reused in dif­fer­ent con­texts, each of which may re­quire its own chan­nel for reply mes­sages.

流程管理器本身使用持久存储（通常是文件或关系数据库）来存储与每个流程实例关联的数据。为了允许 Web 界面查询订单的状态，我们可以向流程管理器或订单数据库发送一条消息。然而，检查状态是一个同步过程，客户希望立即得到响应。由于Web界面是自定义应用程序，因此我们决定直接访问订单数据库来查询订单状态。这种形式的共享数据库是最简单、最有效的方法，并且我们始终确保Web界面显示最新的状态。这种方法的潜在缺点是 Web 界面与数据库紧密耦合，这是我们愿意采取的权衡。

The Pro­cess Man­ager itself uses a per­sist­ent store (typ­ic­ally files or a re­la­tional data­base) to store data as­so­ci­ated with each pro­cess in­stance. To allow the Web in­ter­face to query the status of an order, we could send a mes­sage to the Pro­cess Man­ager or the order data­base. How­ever, check­ing status is a syn­chron­ous pro­cessthe cus­tomer ex­pects the re­sponse right away. Be­cause the Web in­ter­face is a custom ap­plic­a­tion, we decide to access the order data­base dir­ectly to query the order status. This form of Shared Data­base is the simplest and most ef­fi­cient ap­proach, and we are always en­sured that the Web in­ter­face dis­plays the most cur­rent status. The po­ten­tial down­side of this ap­proach is that the Web in­ter­face is tightly coupled to the data­base, a trade-off that we are will­ing to take.

将系统公开为服务的一个困难是由于许多遗留系统在构建时没有考虑到返回地址等功能。因此，我们用智能代理“包装”对遗留系统的访问。该智能代理通过附加功能增强了基本系统服务，使其能够参与 SOA。为此，智能代理拦截来自基本服务的请求和回复消息（见图）。

One dif­fi­culty in ex­pos­ing sys­tems as ser­vices res­ults from the fact that many legacy sys­tems were not built with fea­tures such as Return Ad­dress in mind. There­fore, we "wrap" access to the legacy system with a Smart Proxy. This Smart Proxy en­hances the basic system ser­vice with ad­di­tional cap­ab­il­ity so that it can par­ti­cip­ate in an SOA. To do this, the Smart Proxy in­ter­cepts both re­quest and reply mes­sages to and from the basic ser­vice (see figure).

插入智能代理将遗留系统转变为共享服务

In­sert­ing a Smart Proxy to Turn a Legacy System into a Shared Ser­vice

智能代理可以存储来自请求消息的信息（例如，请求者指定的返回地址）并使用该信息来处理回复消息（例如，将其路由到正确的回复通道）。智能代理对于跟踪外部服务的服务质量（例如响应时间）也非常有用。

The Smart Proxy can store in­form­a­tion from the re­quest mes­sage (e.g., the Return Ad­dress spe­cified by the re­questor) and use this in­form­a­tion to pro­cess the reply mes­sage, (e.g., route it to the cor­rect reply chan­nel). A Smart Proxy is also very useful to track qual­ity of ser­vice (e.g., re­sponse times) of an ex­ternal ser­vice.

更换地址

Change Ad­dress

WGRUS 需要处理多个地址。例如，发票必须发送到客户的帐单地址，而货物则运送到送货地址。我们希望允许客户通过Web界面维护所有这些地址，以消除不必要的手动步骤。

WGRUS needs to deal with a number of ad­dresses. For ex­ample, the in­voice has to be sent to the cus­tomer's billing ad­dress, while the goods are shipped to the ship­ping ad­dress. We want to allow the cus­tomer to main­tain all these ad­dresses through the Web in­ter­face to elim­in­ate un­ne­ces­sary manual steps.

我们可以选择两种基本方法来获取正确的账单和送货地址到账单和送货系统：

We can choose between two basic ap­proaches to get the cor­rect billing and ship­ping ad­dresses to the billing and ship­ping sys­tems:

• 每条新订单消息中都包含地址数据

• In­clude ad­dress data with every New Order mes­sage

• 在每个系统中存储地址数据并复制更改

• Store ad­dress data in each system and rep­lic­ate changes

第一个选项的优点是我们可以使用现有的集成通道来传输附加信息。一个潜在的缺点是流经中间件基础设施的额外数据；即使地址更改的频率可能要低得多，我们也会将地址数据与每个订单一起传递。

The first option has the ad­vant­age that we can use an ex­ist­ing in­teg­ra­tion chan­nel to trans­port the ad­di­tional in­form­a­tion. A po­ten­tial down­side is the ad­di­tional data flow­ing across the mid­dle­ware in­fra­struc­ture; we pass the ad­dress data along with every order even though the ad­dress may change much less fre­quently.

在实施第一个选项时，我们需要考虑到计费和运输系统是打包的应用程序，并且在设计时可能没有考虑到集成。因此，他们不太可能接受新订单的地址，而是使用存储在本地数据库中的地址。为了使系统能够使用新订单消息更新地址，我们需要在计费系统（和运输系统）中执行两个功能：首先，我们必须更新地址，然后我们必须发送账单（或运送商品）。由于两条消息的顺序很重要，因此我们插入一个简单的流程管理器接收新订单消息的组件（其中包括当前的送货和帐单地址，并向帐单（或送货）系统发布两条单独的消息（见图）。

When im­ple­ment­ing the first option, we need to con­sider that the billing and ship­ping sys­tems are pack­aged ap­plic­a­tions and were likely not de­signed with in­teg­ra­tion in mind. As such, they are un­likely to be able to accept ad­dresses with a new order but rather use the ad­dress that is stored in their local data­base. To enable the sys­tems to update the ad­dress with the New Order mes­sage, we need to ex­ecute two func­tions in the billing system (and the ship­ping system): First, we must update the ad­dress, and then we must send the bill (or ship the goods). Be­cause the order of the two mes­sages mat­ters, we insert a simple Pro­cess Man­ager com­pon­ent that re­ceives a New Order mes­sage (which in­cludes the cur­rent ship­ping and billing ad­dresses and pub­lishes two sep­ar­ate mes­sages to the billing (or ship­ping) system (see figure).

在新订单消息中包含地址数据

In­clud­ing Ad­dress Data in the New Order Mes­sage

我们需要记住，通道适配器要求消息采用应用程序使用的专有格式（使用所谓的私有消息）。由于新订单消息以规范消息格式到达，因此我们需要在两种格式之间执行转换。我们可以将转换构建到Process Manager 中，但实际上我们更喜欢外部消息转换器，以便Process不会受到应用程序所需的可能复杂的数据格式的影响。

We need to keep in mind that the Chan­nel Ad­apters re­quire mes­sages to be format­ted in the pro­pri­et­ary formats used by the ap­plic­a­tions (using so-called private mes­sages). Be­cause the New Order mes­sage ar­rives in the ca­non­ical mes­sage format, we need to per­form a trans­la­tion between the two formats. We could build the trans­form­a­tion into the Pro­cess Man­ager, but we ac­tu­ally prefer ex­ternal Mes­sage Trans­lat­ors so that the logic inside the Pro­cess Man­ager is not af­fected by the pos­sibly com­plic­ated data format re­quired by the ap­plic­a­tions.

第二个选项使用数据复制将地址更改传播到所有受影响的系统，独立于新订单流程。每当 Web 界面中的地址信息发生更改时，我们都会使用发布-订阅通道将更改传播到所有感兴趣的系统。 系统在内部存储更新后的地址，并在订单消息到达时使用它。这种方法减少了消息流量（假设客户更改地址的频率低于下订单的频率）。它还可以减少系统之间的耦合。任何使用地址的系统都可以订阅ADDRESS_CHANGE通道，而不会影响任何其他系统。

The second option uses data rep­lic­a­tion to propag­ate ad­dress changes to all af­fected sys­tems in­de­pend­ently of the New Order pro­cess. Whenever the ad­dress in­form­a­tion changes in the Web in­ter­face, we propag­ate the changes to all in­ter­ested sys­tems using a Pub­lish-Sub­scribe Chan­nel. The sys­tems store the up­dated ad­dress in­tern­ally and use it when an Order mes­sage ar­rives. This ap­proach re­duces mes­sage traffic (as­sum­ing cus­tom­ers change ad­dresses less fre­quently than they place orders). It can also reduce coup­ling between sys­tems. Any system that uses an ad­dress can sub­scribe to the AD­DRESS_CHANGE chan­nel without af­fect­ing any other sys­tems.

由于我们正在处理多种类型的地址（送货地址和帐单地址），因此我们需要确保每个系统中仅存储正确类型的地址。如果地址是帐单地址，我们需要避免向运输系统发送地址更改消息。我们通过使用消息过滤器来实现这一点，该器仅传递符合特定条件的消息（见图）。

Be­cause we are deal­ing with mul­tiple types of ad­dresses (ship­ping and billing ad­dresses), we need to make sure that only the right type of ad­dress is stored in each system. We need to avoid send­ing an ad­dress change mes­sage to the ship­ping system if the ad­dress is a billing ad­dress. We ac­com­plish this by using Mes­sage Fil­ters that pass only mes­sages match­ing cer­tain cri­teria (see figure).

我们还使用消息转换器将通用地址更改消息转换为应用程序使用的特定消息格式。在这种情况下，我们不必为Web 界面使用消息转换器，因为我们将规范数据模型定义为与 Web 界面应用程序的格式相同。如果我们想在未来引入其他更改地址的方式，这可能会限制我们的灵活性，但目前已经足够了。

We also use Mes­sage Trans­lat­ors to trans­late the gen­eric Ad­dress Change mes­sage into the spe­cific mes­sage format used by the ap­plic­a­tions. In this case, we do not have to use a Mes­sage Trans­lator for the Web in­ter­face be­cause we define the Ca­non­ical Data Model as equal to the format of the Web in­ter­face ap­plic­a­tion. This could limit our flex­ib­il­ity if we want to in­tro­duce other ways of chan­ging ad­dresses in the future, but for now it is suf­fi­cient.

通过单独的发布-订阅通道传播地址更改

Propagat­ing Ad­dress Changes via a Sep­ar­ate Pub­lish-Sub­scribe Chan­nel

运输和计费系统都将地址存储在关系数据库中，因此我们使用数据库通道适配器来更新每个系统中的数据。

Both the ship­ping and the billing sys­tems store ad­dresses in a re­la­tional data­base, so we use a data­base Chan­nel Ad­apter to update the data in each system.

我们如何在这两个选项之间做出决定？在我们的情况下，消息流量并不是什么大问题，因为我们每天只处理几百个订单，因此任何一种解决方案都相当有效。主要的决策驱动因素将是应用程序的内部结构。我们可能无法将地址直接插入数据库，而是通过应用程序的业务层。在这种情况下，应用程序可以执行额外的验证步骤并记录地址更改活动。系统甚至可以编程为每次地址更改时通过电子邮件向客户发送确认消息。如果每个订单都进行更新，这会变得非常烦人。

How do we decide between the two op­tions? In our situ­ation, the mes­sage traffic is not much of a con­cern be­cause we pro­cess only a few hun­dred orders a day, so either solu­tion would be reas­on­ably ef­fi­cient. The main de­cision driver is going to be the in­ternal struc­ture of the ap­plic­a­tions. We may not be able to insert the ad­dresses dir­ectly into the data­base, but rather through the ap­plic­a­tions' busi­ness layer. In this case, the ap­plic­a­tions may per­form ad­di­tional val­id­a­tion steps and record the ad­dress change activ­ity. The system may even be pro­grammed to e-mail a con­firm­a­tion mes­sage to the cus­tomer every time the ad­dress changes. This would get very an­noy­ing if the update oc­curred with every order. Such a con­di­tion would favor propagat­ing ad­dress changes using ded­ic­ated mes­sages that are sent only when the cus­tomer ac­tu­ally changes the ad­dress.

一般来说，我们更喜欢定义明确、独立的业务操作，例如“更改地址”和“下订单”，因为它们为我们编排业务流程提供了更大的灵活性。这一切都归结为粒度和相关权衡的问题。由于进行过多的远程调用或发送消息，细粒度的接口可能会导致系统运行缓慢。例如，想象一个接口公开一个单独的方法来更改每个地址字段。如果通信发生在单个应用程序内（仅更新那些已更改的字段），则此方法将非常有效。在集成场景中，发送六到七条消息来更新地址将是一笔巨大的开销，另外，我们还必须处理同步各个消息的问题。细粒度的接口也会导致紧密的耦合。如果我们通过添加新字段来更改地址格式，则必须定义新的消息格式并更改所有其他应用程序以发送附加消息。

In gen­eral, we prefer well-defined, self-con­tained busi­ness ac­tions such as "Change Ad­dress" and "Place Order" be­cause they give us more flex­ib­il­ity in or­ches­trat­ing the busi­nesses pro­cesses. It all comes down to a ques­tion of gran­u­lar­ity and the as­so­ci­ated trade-offs. Fine-grained in­ter­faces can lead to slug­gish sys­tems due to an ex­cess­ive number of remote calls being made or mes­sages being sent. For ex­ample, ima­gine an in­ter­face that ex­poses a sep­ar­ate method to change each ad­dress field. This ap­proach would be ef­fi­cient if the com­mu­nic­a­tion hap­pens inside a single ap­plic­a­tionyou update only those fields that changed. In an in­teg­ra­tion scen­ario, send­ing six or seven mes­sages to update an ad­dress would be a sig­ni­fic­ant over­head, plus we would have to deal with syn­chron­iz­ing the in­di­vidual mes­sages. Fine-grained in­ter­faces also lead to tight coup­ling. If we change the ad­dress format by adding a new field, we have to define new mes­sage formats and change all other ap­plic­a­tions to send an ad­di­tional mes­sage.

粗粒度接口可以解决这些问题，但需要付出一定的代价。我们发送的消息较少，因此效率更高且耦合程度较低。然而，过于粗糙的接口会限制我们的灵活性。如果“发送发票”和“更改地址”合并为一个外部函数，那么我们将永远无法在不发送帐单的情况下更改地址。因此，一如既往，最好的答案是折中方案，并且取决于现实生活场景中的具体权衡。

Coarse-grained in­ter­faces solve these issues, but at a cost. We send fewer mes­sages and are there­fore more ef­fi­cient and less tightly coupled. How­ever, in­ter­faces that are too coarse can limit our flex­ib­il­ity. If Send In­voice and Change Ad­dress are com­bined into one ex­ternal func­tion, we will never be able to change an ad­dress without send­ing a bill. So, as always, the best answer is the happy medium and de­pends on the spe­cific trade-offs at work in the real-life scen­ario.

新目录

New Cata­log

要下订单，客户需要在线查看当前提供的商品及其价格。WGRUS 的目录由各个供应商的产品驱动。然而，WGRUS 向客户提供的服务之一是允许他们在同一网站上查看小部件和小工具，并在一个订单中订购两种类型的商品。此功能是信息门户场景的示例，我们将多个源的信息组合到一个视图中。

To place orders, cus­tom­ers need to see the cur­rently offered items and their prices online. WGRUS's cata­log is driven by the of­fer­ings from the re­spect­ive sup­pli­ers. How­ever, one of the ser­vices that WGRUS provides to its cus­tom­ers is al­low­ing them to view wid­gets and gad­gets on the same site and to order both types of items in a single order. This func­tion is an ex­ample of an In­form­a­tion Portal scen­ari­owe com­bine in­form­a­tion from mul­tiple sources into a single view.

事实证明，两家供应商每三个月更新一次产品目录。因此，创建实时消息传递基础设施来将目录更改从供应商传播到 WGRUS 的意义相对较小。相反，我们使用文件传输集成将目录数据从供应商移动到 WGRUS。使用文件的另一个优点是可以使用 FTP 或类似协议在公共网络上轻松高效地传输文件。相比之下，大多数异步消息传递基础设施在公共互联网上无法正常工作。

It turns out that both sup­pli­ers update their product cata­log once every three months. There­fore, it makes re­l­at­ively little sense to create a real-time mes­saging in­fra­struc­ture to propag­ate cata­log changes from the sup­pli­ers to WGRUS. In­stead, we use File Trans­fer in­teg­ra­tion to move cata­log data from sup­pli­ers to WGRUS. The other ad­vant­age of using files is that they are easily and ef­fi­ciently trans­por­ted across public net­works using FTP or sim­ilar pro­to­cols. In com­par­ison, most asyn­chron­ous mes­saging in­fra­struc­tures do not work well over the public In­ter­net.

我们仍然可以使用转换器和适配器将数据转换为我们的内部目录格式。然而，这些翻译人员一次处理整个目录，而不是一次处理一个项目。如果我们处理相同格式的大量数据，这种方法会更有效。

We still can use trans­lat­ors and ad­apters to trans­form the data to our in­ternal cata­log format. How­ever, these trans­lat­ors pro­cess a whole cata­log at once in­stead of one item at a time. This ap­proach is much more ef­fi­cient if we are deal­ing with large amounts of data in the same format.

通过文件传输更新目录数据

Up­dat­ing Cata­log Data via File Trans­fer

公告

An­nounce­ments

为了改善业务，我们希望每隔一段时间就向客户宣布特价活动。为了避免打扰客户，我们允许每个客户指定他们感兴趣的消息。我们还希望将特定的消息发送给特定的客户子集。例如，我们可能只向优先客户宣布特别优惠。当我们需要向多个收件人发送信息时，我们会立即想到发布-订阅通道。然而，发布-订阅通道有一些缺点。首先，它允许任何订阅者在发布者不知情的情况下收听已发布的消息。例如，我们不希望小客户收到针对大批量客户的特别优惠。发布-订阅通道的第二个缺点是它们只能在本地网络上有效地工作。如果我们通过发布-订阅通道跨广域网发送数据，我们必须向每个收件人发送单独的消息副本。如果收件人对该消息不感兴趣，我们就会产生不必要的网络流量。

In order to im­prove busi­ness, we want to an­nounce spe­cials to our cus­tom­ers every once in a while. To avoid an­noy­ing the cus­tom­ers, we allow each cus­tomer to spe­cify which mes­sages in­terest them. We also want to target spe­cific mes­sages to a spe­cific subset of cus­tom­ers. For ex­ample, we may an­nounce spe­cial deals only to pre­ferred cus­tom­ers. When we need to send in­form­a­tion to mul­tiple re­cip­i­ents, a Pub­lish-Sub­scribe Chan­nel im­me­di­ately comes to mind. How­ever, a Pub­lish-Sub­scribe Chan­nel has some dis­ad­vant­ages. First, it allows any sub­scriber to listen to the pub­lished mes­sages without the pub­lisher's know­ledge. For ex­ample, we would not want smal­ler cus­tom­ers to re­ceive spe­cial offers in­ten­ded for high-volume cus­tom­ers. The second down­side of Pub­lish-Sub­scribe Chan­nels is that they work ef­fi­ciently only on local net­works. If we send data across wide-area net­works via a Pub­lish-Sub­scribe Chan­nel, we have to send a sep­ar­ate copy of the mes­sage to each re­cip­i­ent. If a re­cip­i­ent is not in­ter­ested in the mes­sage, we would have in­curred un­ne­ces­sary net­work traffic.

因此，我们应该寻找一种解决方案，允许订阅者发布他们的订阅偏好，然后仅向感兴趣（和授权）的客户发送单独的消息。为了执行此功能，我们使用动态收件人列表。动态收件人列表是两种消息路由模式的组合。收件人列表是一个将单个消息传播到一组收件人的路由器。接收者列表和发布-订阅通道之间的主要区别在于，接收者列表专门针对每个收件人，因此可以严格控制谁接收消息。动态路由器是一种其路由算法可以根据控制消息而改变的路由器。这些控制消息可以采用订阅者发出的订阅偏好的形式。动态收件人列表是这两种模式结合的结果

There­fore, we should look for a solu­tion that allows sub­scribers to issue their sub­scrip­tion pref­er­ences and then send in­di­vidual mes­sages only to in­ter­ested (and au­thor­ized) cus­tom­ers. To per­form this func­tion, we use a Dy­namic Re­cip­i­ent List. A dy­namic Re­cip­i­ent List is the com­bin­a­tion of two Mes­sage Rout­ing pat­terns. A Re­cip­i­ent List is a router that propag­ates a single mes­sage to a set of re­cip­i­ents. The main dif­fer­ence between the Re­cip­i­ent List and a Pub­lish-Sub­scribe Chan­nel is that the Re­cip­i­ent List ad­dresses each re­cip­i­ent spe­cific­ally and there­fore has tight con­trol over who re­ceives mes­sages. A Dy­namic Router is a router whose rout­ing al­gorithm can change based on con­trol mes­sages. These con­trol mes­sages can take the form of sub­scrip­tion pref­er­ences issued by the sub­scribers. A dy­namic Re­cip­i­ent List is the result of com­bin­ing these two pat­terns

发送带有动态收件人列表的公告

Send­ing An­nounce­ments with a Dy­namic Re­cip­i­ent List

如果客户通过电子邮件接收公告，则这些模式的实现可以使用通常由电子邮件系统提供的邮件列表功能。然后，每个收件人渠道都通过电子邮件地址进行标识。同样，如果客户更喜欢通过 Web 服务接口接收公告，则每个接收者通道都由 SOAP 请求实现，并且通道地址是 Web 服务的 URI。此示例说明我们用于描述解决方案设计的模式独立于特定的传输技术。

If cus­tom­ers re­ceive an­nounce­ments via e-mail, the im­ple­ment­a­tion of these pat­terns can use the mail­ing list's fea­tures typ­ic­ally sup­plied by e-mail sys­tems. Each re­cip­i­ent chan­nel is then iden­ti­fied by an e-mail ad­dress. Like­wise, if cus­tom­ers prefer to re­ceive an­nounce­ments via a Web ser­vices in­ter­face, each re­cip­i­ent chan­nel is im­ple­men­ted by a SOAP re­quest, and the chan­nel ad­dress is the URI of the Web ser­vice. This ex­ample il­lus­trates that the pat­terns we use to de­scribe the solu­tion design are in­de­pend­ent of a spe­cific trans­port tech­no­logy.

测试和监控

Test­ing and Mon­it­or­ing

监视消息的正确执行是一项关键的操作和支持功能。消息存储可以为我们提供一些重要的业务指标，例如履行订单的平均时间。但是，我们可能需要更详细的信息才能成功运行集成解决方案。假设我们增强了解决方案以访问外部信用机构，以更好地评估客户的信用状况。即使我们没有显示未付款项，如果客户的信用评级特别差，我们也可能会拒绝客户的订单。这对于没有我们付款历史的新客户特别有用。由于该服务是由外部提供商提供的，因此我们需要为其使用付费。为了验证提供商的发票，我们希望跟踪我们的实际使用情况并核对两个报告。我们不能简单地看订单数量，因为业务逻辑可能不会要求对长期客户进行外部信用检查。此外，我们可能与外部提供商签订了服务质量 (QoS) 协议。例如，如果响应时间超过指定时间，我们可能无需为请求付费。

Mon­it­or­ing the cor­rect ex­e­cu­tion of mes­sages is a crit­ical op­er­a­tions and sup­port func­tion. The Mes­sage Store can provide us with some im­port­ant busi­ness met­rics, such as the av­er­age time to ful­fill an order. How­ever, we may need more de­tailed in­form­a­tion for the suc­cess­ful op­er­a­tion of an in­teg­ra­tion solu­tion. Let's assume we en­hance our solu­tion to access an ex­ternal credit agency to better assess our cus­tomer's credit stand­ing. Even if we show no out­stand­ing pay­ments, we may want to de­cline a cus­tomer's order if the cus­tomer's credit rank­ing is par­tic­u­larly poor. This is es­pe­cially useful for new cus­tom­ers who do not have a pay­ment his­tory with us. Be­cause the ser­vice is provided by an out­side pro­vider, we are charged for its use. To verify the pro­vider's in­voice, we want to track our actual usage and re­con­cile the two re­ports. We cannot simply go by the number of orders, be­cause the busi­ness logic may not re­quest an ex­ternal credit check for long-stand­ing cus­tom­ers. Also, we may have a qual­ity of ser­vice (QoS) agree­ment with the ex­ternal pro­vider. For ex­ample, if the re­sponse time ex­ceeds a spe­cified time, we may not have to pay for the re­quest.

为了确保正确计费，我们希望跟踪我们发出的请求数量以及相关响应到达所需的时间。我们必须能够处理两种具体情况。首先，外部服务一次可以处理多个请求，因此我们需要能够匹配请求和回复消息。其次，由于我们将外部服务视为企业内部的共享服务，因此我们希望允许服务使用者指定一个Return Address ，即服务应发送回复消息的通道。不知道回复发送到哪个通道可能会导致匹配请求和回复消息变得困难。

To make sure we are being billed cor­rectly, we want to track the number of re­quests we make and the time it takes for the as­so­ci­ated re­sponse to arrive. We have to be able to deal with two spe­cific situ­ations. First, the ex­ternal ser­vice can pro­cess more than one re­quest at a time, so we need to be able to match up re­quest and reply mes­sages. Second, since we treat the ex­ternal ser­vice as a shared ser­vice inside our en­ter­prise, we want to allow the ser­vice con­sumer to spe­cify a Return Ad­dress, the chan­nel where the ser­vice should send the reply mes­sage. Not know­ing to which chan­nel the reply is being sent can make it dif­fi­cult to match re­quest and reply mes­sages.

智能代理再次是答案。我们在任何服务使用者和外部服务之间插入智能代理。智能代理拦截对服务的每个请求，并用固定的回复通道替换服务消费者指定的返回地址。这会导致服务将所有回复消息发送到智能代理指定的通道。代理存储原始的返回地址，以便它可以将回复消息转发到消费者最初指定的通道。智能代理还测量来自外部服务的请求和回复消息之间经过的时间。这智能代理将此数据发布到控制总线。控制总线连接到管理控制台，该控制台从许多不同的组件收集指标。

Once again, the Smart Proxy is the answer. We insert the Smart Proxy between any ser­vice con­sumer and the ex­ternal ser­vice. The Smart Proxy in­ter­cepts each re­quest to the ser­vice and re­places the Return Ad­dress spe­cified by the ser­vice con­sumer with a fixed reply chan­nel. This causes the ser­vice to send all reply mes­sages to the chan­nel spe­cified by the Smart Proxy. The proxy stores the ori­ginal Return Ad­dress so that it can for­ward the reply mes­sage to the chan­nel ori­gin­ally spe­cified by the con­sumer. The Smart Proxy also meas­ures the time elapsed between re­quest and reply mes­sages from the ex­ternal ser­vice. The Smart Proxy pub­lishes this data to the Con­trol Bus. The Con­trol Bus con­nects to a man­age­ment con­sole that col­lects met­rics from many dif­fer­ent com­pon­ents.

插入智能代理来跟踪响应时间

In­sert­ing a Smart Proxy to Track Re­sponse Times

除了跟踪我们对外部信用服务的使用情况外，我们还希望确保该服务正常运行。智能代理可以向管理控制台报告在指定超时时间内未收到回复消息的情况。外部服务返回回复消息但消息中的结果不正确的情况更难以检测。例如，如果外部服务出现故障并为每个客户返回零信用评分，我们最终会拒绝每个订单。有两种机制可以帮助我们防止这种情况的发生。首先，我们可以定期将测试消息注入到请求流中。此测试消息请求特定人员的分数以便知道结果。然后，我们可以使用测试数据验证器不仅检查是否收到回复，还检查消息内容的准确性。由于智能代理支持返回地址，测试数据生成器可以指定一个特殊的回复通道来将测试回复与常规回复分开（见图）。

Be­sides track­ing our usage of the ex­ternal credit ser­vice, we also want to make sure that the ser­vice is work­ing cor­rectly. The Smart Proxy can report to the man­age­ment con­sole cases where no reply mes­sage is re­ceived within a spe­cified time-out period. Much harder to detect are cases where the ex­ternal ser­vice re­turns a reply mes­sage but the res­ults in the mes­sage are in­cor­rect. For ex­ample, if the ex­ternal ser­vice mal­func­tions and re­turns a credit score of zero for every cus­tomer, we would end up deny­ing every order. There are two mech­an­isms that can help us pro­tect against such a scen­ario. First, we can peri­od­ic­ally inject a Test Mes­sage into the re­quest stream. This Test Mes­sage re­quests the score for a spe­cific person so that the result is known. We can then use a test data veri­fier to check not only that a reply was re­ceived but also the ac­cur­acy of the mes­sage con­tent. Be­cause the Smart Proxy sup­ports Return Ad­dresses, the test data gen­er­ator can spe­cify a spe­cial reply chan­nel to sep­ar­ate test replies from reg­u­lar replies (see figure).

插入测试消息以验证结果是否准确

In­sert­ing Test Mes­sages to Verify Ac­cur­ate Res­ults

检测故障服务的另一个有效策略是进行统计样本。例如，由于客户信誉不佳，我们预计平均会拒绝不到十分之一的订单。如果我们连续拒绝超过五个订单，这可能表明外部服务或某些业务逻辑出现故障。管理控制台可以通过电子邮件将五个订单发送给管理员，然后管理员可以快速查看数据以验证拒绝是否合理。

An­other ef­fect­ive strategy to detect mal­func­tion­ing ser­vices is to take a stat­ist­ical sample. For ex­ample, we may expect to de­cline an av­er­age of less than one in 10 orders due to cus­tom­ers' poor stand­ing. If we de­cline more than five orders in a row, this may be an in­dic­a­tion that an ex­ternal ser­vice or some busi­ness logic is mal­func­tion­ing. The man­age­ment con­sole could e-mail the five orders to an ad­min­is­trator, who can then take a quick look at the data to verify whether the re­jec­tions were jus­ti­fied.

概括

Summary

我们已经使用不同的集成策略（例如文件传输、共享数据库和异步消息传递）完成了相当广泛的集成场景。我们路由、拆分和聚合消息。我们引入了流程管理器以提供更大的灵活性。我们还添加了监控解决方案正确运行的功能。虽然这个示例的要求确实得到了简化，但我们必须考虑的问题和设计权衡却是非常现实的。解决方案图和描述重点介绍了我们如何使用供应商中立和技术中立的语言来描述每个解决方案，这种语言比高级序列图准确得多。

We have walked through a fairly ex­tens­ive in­teg­ra­tion scen­ario using dif­fer­ent in­teg­ra­tion strategies such as File Trans­fer, Shared Data­base, and asyn­chron­ous Mes­saging. We routed, split, and ag­greg­ated mes­sages. We in­tro­duced a Pro­cess Man­ager to allow for more flex­ib­il­ity. We also added func­tions to mon­itor the cor­rect op­er­a­tion of the solu­tion. While the re­quire­ments for this ex­ample were ad­mit­tedly sim­pli­fied, the issues and design trade-offs we had to con­sider are very real. The solu­tion dia­grams and de­scrip­tions high­light how we can de­scribe each solu­tion in a vendor-neut­ral and tech­no­logy-neut­ral lan­guage that is much more ac­cur­ate than a high-level se­quence dia­gram.

本章中的集成场景主要关注如何连接现有应用程序。有关如何从自定义应用程序内部发布和使用消息的详细说明，请参阅第 6 章“Interlude：简单消息传递”和第 9 章“Interlude：组合消息传递”中的示例。

The in­teg­ra­tion scen­ario in this chapter fo­cuses primar­ily on how to con­nect ex­ist­ing ap­plic­a­tions. For a de­tailed de­scrip­tion of how to pub­lish and con­sume mes­sages from inside a custom ap­plic­a­tion, see the ex­amples in Chapter 6, "In­ter­lude: Simple Mes­saging," and Chapter 9, "In­ter­lude: Com­posed Mes­saging."

本书的其余部分包含我们在解决方案设计中使用的每种模式的详细描述和代码示例，以及许多相关模式。这些模式按其主要意图分为基本模式、通道模式、消息模式、路由模式、转换模式、端点模式和系统管理模式。这种安排可以轻松地按顺序读取所有模式或查找单个模式作为参考。

The re­mainder of the book con­tains de­tailed de­scrip­tions and code ex­amples for each of the pat­terns that we used in our solu­tion design, as well as many re­lated pat­terns. The pat­terns are cat­egor­ized by their primary intent between base pat­terns, chan­nel pat­terns, mes­sage pat­terns, rout­ing pat­terns, trans­form­a­tion pat­terns, en­d­point pat­terns, and system man­age­ment pat­terns. This ar­range­ment makes it easy to read all pat­terns in se­quence or to look up in­di­vidual pat­terns as a ref­er­ence.

第 2 章集成样式

Chapter 2. Integration Styles

介绍

In­tro­duc­tion

文件传输

File Trans­fer

共享数据库

Shared Data­base

远程过程调用

Remote Pro­ced­ure In­voc­a­tion

消息传递

Mes­saging

介绍

Introduction

企业集成的任务是使不同的应用程序协同工作以产生一组统一的功能。这些应用程序可以在内部定制开发或从第三方供应商处购买。它们可能在多台计算机上运行，​​这些计算机可能代表多个平台，并且可能在地理上分散。某些应用程序可能由业务合作伙伴或客户在企业外部运行。其他应用程序在设计时可能没有考虑到集成，并且很难更改。这些问题和其他类似问题使应用程序集成变得复杂。本章探讨了有助于克服这些挑战的多种集成方法。

En­ter­prise in­teg­ra­tion is the task of making dis­par­ate ap­plic­a­tions work to­gether to pro­duce a uni­fied set of func­tion­al­ity. These ap­plic­a­tions can be custom de­ve­loped in house or pur­chased from third-party vendors. They likely run on mul­tiple com­puters, which may rep­res­ent mul­tiple plat­forms, and may be geo­graph­ic­ally dis­persed. Some of the ap­plic­a­tions may be run out­side of the en­ter­prise by busi­ness part­ners or cus­tom­ers. Other ap­plic­a­tions might not have been de­signed with in­teg­ra­tion in mind and are dif­fi­cult to change. These issues and others like them make ap­plic­a­tion in­teg­ra­tion com­plic­ated. This chapter ex­plores mul­tiple in­teg­ra­tion ap­proaches that can help over­come these chal­lenges.

应用程序集成标准

Ap­plic­a­tion In­teg­ra­tion Cri­teria

什么是良好的应用程序集成？如果集成需求始终相同，那么就只有一种集成方式。然而，与任何复杂的技术工作一样，应用程序集成涉及一系列考虑因素和后果，任何集成机会都应考虑到这些因素和后果。

What makes good ap­plic­a­tion in­teg­ra­tion? If in­teg­ra­tion needs were always the same, there would be only one in­teg­ra­tion style. Yet, like any com­plex tech­no­lo­gical effort, ap­plic­a­tion in­teg­ra­tion in­volves a range of con­sid­er­a­tions and con­se­quences that should be taken into ac­count for any in­teg­ra­tion op­por­tun­ity.

根本标准是是否使用应用程序集成。如果您可以开发一个不需要与任何其他应用程序协作的独立应用程序，则可以完全避免整个集成问题。但实际上，即使是一个简单的企业也有多个应用程序需要协同工作，以便为企业的员工、合作伙伴和客户提供统一的体验。

The fun­da­mental cri­terion is whether to use ap­plic­a­tion in­teg­ra­tion at all. If you can de­velop a single, stan­dalone ap­plic­a­tion that doesn't need to col­lab­or­ate with any other ap­plic­a­tions, you can avoid the whole in­teg­ra­tion issue en­tirely. Real­ist­ic­ally, though, even a simple en­ter­prise has mul­tiple ap­plic­a­tions that need to work to­gether to provide a uni­fied ex­per­i­ence for the en­ter­prise's em­ploy­ees, part­ners, and cus­tom­ers.

以下是其他一些主要决策标准。

The fol­low­ing are some other main de­cision cri­teria.

应用程序 耦合应用程序应该最大限度地减少彼此之间的依赖性，以便每个应用程序都可以在不给其他应用程序带来问题的情况下发展。正如第 1 章“使用模式解决集成问题”中所解释的，紧密耦合的应用程序对其他应用程序如何工作做出了许多假设；当应用程序发生变化并打破这些假设时，它们之间的集成就会中断。因此，用于集成应用程序的接口应该足够具体以实现有用的功能，但也应该足够通用以允许实现根据需要进行更改。

侵入性 将应用程序 集成，开发人员应努力尽量减少对应用程序的更改以及所需的集成代码量。然而，为了提供良好的集成功能，通常需要进行更改和新代码，并且对应用程序影响最小的方法可能无法提供与企业的最佳集成。

技术选择 不同的集成技术需要不同数量的专用软件和硬件。此类工具可能价格昂贵，可能导致供应商锁定，并且会增加开发人员的学习曲线。另一方面，从头开始创建集成解决方案通常会比最初预期付出更多的努力，并且可能意味着重新发明轮子。

数据格式 集成应用程序必须就它们交换的数据的格式达成一致。更改现有应用程序以使用统一的数据格式可能很困难或不可能。或者，中间转换器可以统一坚持不同数据格式的应用程序。一个相关的问题是数据格式的演变和可扩展性，格式如何随时间变化以及这种变化将如何影响应用程序。

数据时效性 集成应最大限度地缩短一个应用程序决定共享某些数据与其他应用程序拥有该数据之间的时间长度。这可以通过频繁且小块地交换数据来实现。然而，将大量数据分成小块可能会导致效率低下。数据共享的延迟必须考虑到集成设计中。理想情况下，一旦共享数据可供使用，接收器应用程序就应该得到通知。共享时间越长，应用程序不同步的机会就越大，集成也就越复杂。

数据或功能 许多 集成解决方案允许应用程序不仅共享数据，还允许共享功能，因为共享功能可以在应用程序之间提供更好的抽象。尽管调用远程应用程序中的功能可能看起来与调用本地功能相同，但其工作方式却截然不同，这对集成的工作效果产生了重大影响。

远程通信计算机 处理通常是同步的，即过程在其子过程执行时等待。然而，调用远程子过程比本地子过程慢得多，因此过程可能不想等待子过程完成；相反，它可能希望异步调用子过程，即启动子过程但同时继续其自己的处理。异步性可以提供更高效的解决方案，但这样的解决方案的设计、开发和调试也更加复杂。

可靠性 远程 连接不仅速度慢，而且可靠性远低于本地函数调用。当一个过程调用单个应用程序内的子过程时，就假定该子过程可用。远程通信时不一定如此；远程应用程序甚至可能没有运行，或者网络可能暂时不可用。可靠的异步通信使源应用程序能够继续执行其他工作，并确信远程应用程序稍后会采取行动。

Ap­plic­a­tion coup­ling In­teg­rated ap­plic­a­tions should min­im­ize their de­pend­en­cies on each other so that each can evolve without caus­ing prob­lems to the others. As ex­plained in Chapter 1, "Solv­ing In­teg­ra­tion Prob­lems Using Pat­terns," tightly coupled ap­plic­a­tions make nu­mer­ous as­sump­tions about how the other ap­plic­a­tions work; when the ap­plic­a­tions change and break those as­sump­tions, the in­teg­ra­tion between them breaks. There­fore, the in­ter­faces for in­teg­rat­ing ap­plic­a­tions should be spe­cific enough to im­ple­ment useful func­tion­al­ity but gen­eral enough to allow the im­ple­ment­a­tion to change as needed.

In­trus­ive­ness When in­teg­rat­ing an ap­plic­a­tion into an en­ter­prise, de­ve­lopers should strive to min­im­ize both changes to the ap­plic­a­tion and the amount of in­teg­ra­tion code needed. Yet, changes and new code are often ne­ces­sary to provide good in­teg­ra­tion func­tion­al­ity, and the ap­proaches with the least impact on the ap­plic­a­tion may not provide the best in­teg­ra­tion into the en­ter­prise.

Tech­no­logy se­lec­tion Dif­fer­ent in­teg­ra­tion tech­niques re­quire vary­ing amounts of spe­cial­ized soft­ware and hard­ware. Such tools can be ex­pens­ive, can lead to vendor lock-in, and can in­crease the learn­ing curve for de­ve­lopers. On the other hand, cre­at­ing an in­teg­ra­tion solu­tion from scratch usu­ally res­ults in more effort than ori­gin­ally in­ten­ded and can mean re­in­vent­ing the wheel.

Data format In­teg­rated ap­plic­a­tions must agree on the format of the data they ex­change. Chan­ging ex­ist­ing ap­plic­a­tions to use a uni­fied data format may be dif­fi­cult or im­pos­sible. Al­tern­at­ively, an in­ter­me­di­ate trans­lator can unify ap­plic­a­tions that insist on dif­fer­ent data formats. A re­lated issue is data format evol­u­tion and ex­tens­ib­il­ityhow the format can change over time and how that change will affect the ap­plic­a­tions.

Data timeli­ness In­teg­ra­tion should min­im­ize the length of time between when one ap­plic­a­tion de­cides to share some data and other ap­plic­a­tions have that data. This can be ac­com­plished by ex­chan­ging data fre­quently and in small chunks. How­ever, chunking a large set of data into small pieces may in­tro­duce in­ef­fi­cien­cies. Latency in data shar­ing must be factored into the in­teg­ra­tion design. Ideally, re­ceiver ap­plic­a­tions should be in­formed as soon as shared data is ready for con­sump­tion. The longer shar­ing takes, the greater the op­por­tun­ity for ap­plic­a­tions to get out of sync and the more com­plex in­teg­ra­tion can become.

Data or func­tion­al­ity Many in­teg­ra­tion solu­tions allow ap­plic­a­tions to share not only data but func­tion­al­ity as well, be­cause shar­ing of func­tion­al­ity can pro­vider better ab­strac­tion between the ap­plic­a­tions. Even though in­vok­ing func­tion­al­ity in a remote ap­plic­a­tion may seem the same as in­vok­ing local func­tion­al­ity, it works quite dif­fer­ently, with sig­ni­fic­ant con­se­quences for how well the in­teg­ra­tion works.

Remote Com­mu­nic­a­tion Com­puter pro­cess­ing is typ­ic­ally syn­chron­ousthat is, a pro­ced­ure waits while its sub­pro­ced­ure ex­ecutes. How­ever, call­ing a remote sub­pro­ced­ure is much slower than a local one so that a pro­ced­ure may not want to wait for the sub­pro­ced­ure to com­plete; in­stead, it may want to invoke the sub­pro­ced­ure asyn­chron­ously, that is, start­ing the sub­pro­ced­ure but con­tinu­ing with its own pro­cess­ing sim­ul­tan­eously. Asyn­chron­icity can make for a much more ef­fi­cient solu­tion, but such a solu­tion is also more com­plex to design, de­velop, and debug.

Re­li­ab­il­ity Remote con­nec­tions are not only slow, but they are much less re­li­able than a local func­tion call. When a pro­ced­ure calls a sub­pro­ced­ure inside a single ap­plic­a­tion, it's a given that the sub­pro­ced­ure is avail­able. This is not ne­ces­sar­ily true when com­mu­nic­at­ing re­motely; the remote ap­plic­a­tion may not even be run­ning or the net­work may be tem­por­ar­ily un­avail­able. Re­li­able, asyn­chron­ous com­mu­nic­a­tion en­ables the source ap­plic­a­tion to go on to other work, con­fid­ent that the remote ap­plic­a­tion will act some­time later.

因此，正如您所看到的，在选择和设计集成方法时必须考虑几个不同的标准。那么问题就变成了，哪种集成方法最能满足这些标准中的哪一个？

So, as you can see, there are sev­eral dif­fer­ent cri­teria that must be con­sidered when choos­ing and design­ing an in­teg­ra­tion ap­proach. The ques­tion then be­comes, Which in­teg­ra­tion ap­proach best ad­dresses which of these cri­teria?

应用程序集成选项

Ap­plic­a­tion In­teg­ra­tion Op­tions

没有一种集成方法能够同等地满足所有标准。因此，随着时间的推移，集成应用程序的多种方法不断发展。各种方法可以概括为四种主要集成风格。

There is no one in­teg­ra­tion ap­proach that ad­dresses all cri­teria equally well. There­fore, mul­tiple ap­proaches for in­teg­rat­ing ap­plic­a­tions have evolved over time. The vari­ous ap­proaches can be summed up in four main in­teg­ra­tion styles.

文件传输 让

共享数据库 让

远程过程调用 让 每个

消息传递 让

File Trans­fer Have each ap­plic­a­tion pro­duce files of shared data for others to con­sume and con­sume files that others have pro­duced.

Shared Data­base Have the ap­plic­a­tions store the data they wish to share in a common data­base.

Remote Pro­ced­ure In­voc­a­tion Have each ap­plic­a­tion expose some of its pro­ced­ures so that they can be in­voked re­motely, and have ap­plic­a­tions invoke those to ini­ti­ate be­ha­vior and ex­change data.

Mes­saging Have each ap­plic­a­tion con­nect to a common mes­saging system, and ex­change data and invoke be­ha­vior using mes­sages.

本章将每种样式作为模式呈现。这四种模式共享相同的问题陈述——集成应用程序的需要和非常相似的上下文。他们的与众不同之处在于寻求更优雅的解决方案的力量。每一种模式都建立在上一种模式的基础上，寻找一种更复杂的方法来解决其前身的缺点。因此，模式顺序反映了复杂性的增加，但也反映了复杂性的增加。

This chapter presents each style as a pat­tern. The four pat­terns share the same prob­lem state­mentthe need to in­teg­rate ap­plic­a­tion­sand very sim­ilar con­texts. What dif­fer­en­ti­ates them are the forces search­ing for a more el­eg­ant solu­tion. Each pat­tern builds on the last, look­ing for a more soph­ist­ic­ated ap­proach to ad­dress the short­com­ings of its pre­de­cessors. Thus, the pat­tern order re­flects an in­creas­ing order of soph­ist­ic­a­tion, but also in­creas­ing com­plex­ity.

诀窍不是每次都选择一种样式，而是针对特定的集成机会选择最佳样式。每种风格都有其优点和缺点。应用程序可以使用多种样式进行集成，以便每个集成点都能利用最适合它的样式。同样，应用程序可以使用不同的样式与不同的应用程序集成，选择最适合其他应用程序的样式。因此，许多集成方法最好被视为多种集成风格的混合体。为了支持这种类型的集成，许多集成和 EAI 中间件产品采用了多种样式的组合，所有这些样式都有效地隐藏在产品的实现中。

The trick is not to choose one style to use every time but to choose the best style for a par­tic­u­lar in­teg­ra­tion op­por­tun­ity. Each style has its ad­vant­ages and dis­ad­vant­ages. Ap­plic­a­tions may in­teg­rate using mul­tiple styles so that each point of in­teg­ra­tion takes ad­vant­age of the style that suits it best. Like­wise, an ap­plic­a­tion may use dif­fer­ent styles to in­teg­rate with dif­fer­ent ap­plic­a­tions, choos­ing the style that works best for the other ap­plic­a­tion. As a result, many in­teg­ra­tion ap­proaches can best be viewed as a hybrid of mul­tiple in­teg­ra­tion styles. To sup­port this type of in­teg­ra­tion, many in­teg­ra­tion and EAI mid­dle­ware products employ a com­bin­a­tion of styles, all of which are ef­fect­ively hidden in the product's im­ple­ment­a­tion.

本书其余部分的模式扩展了消息传递集成风格。我们专注于消息传递，因为我们相信它在集成标准之间提供了良好的平衡，但也是最难使用的风格。因此，消息传递仍然是集成风格中最难理解的技术，也是一种成熟的技术，其模式可以快速解释如何最好地使用它。最后，消息传递是许多商业 EAI 产品的基础，因此解释如何很好地使用消息传递对于教会您如何使用这些产品也大有帮助。本节的重点是强调与应用程序集成相关的问题以及消息传递如何融入其中。

The pat­terns in the re­mainder of this book expand on the Mes­saging in­teg­ra­tion style. We focus on mes­saging be­cause we be­lieve that it provides a good bal­ance between the in­teg­ra­tion cri­teria but is also the most dif­fi­cult style to work with. As a result, mes­saging is still the least well un­der­stood of the in­teg­ra­tion styles and a tech­no­logy ripe with pat­terns that quickly ex­plain how to use it best. Fi­nally, mes­saging is the basis for many com­mer­cial EAI products, so ex­plain­ing how to use mes­saging well also goes a long way in teach­ing you how to use those products. The focus of this sec­tion is to high­light the issues in­volved with ap­plic­a­tion in­teg­ra­tion and how mes­saging fits into the mix.

文件传输

File Transfer

马丁·福勒

by Martin Fowler

一个企业有多个独立构建的应用程序，这些应用程序使用不同的语言和平台。

An en­ter­prise has mul­tiple ap­plic­a­tions that are being built in­de­pend­ently, with dif­fer­ent lan­guages and plat­forms.

在理想的世界中，您可能会想象一个组织通过一个单一的、有凝聚力的软件进行操作，该软件从一开始就被设计为以统一和连贯的方式工作。当然，即使是最小的操作也不会这样工作。多个软件处理企业的不同方面。这是由于多种原因造成的。

In an ideal world, you might ima­gine an or­gan­iz­a­tion op­er­at­ing from a single, co­hes­ive piece of soft­ware, de­signed from the be­gin­ning to work in a uni­fied and co­her­ent way. Of course, even the smal­lest op­er­a­tions don't work like that. Mul­tiple pieces of soft­ware handle dif­fer­ent as­pects of the en­ter­prise. This is due to a host of reas­ons.

• 人们购买由外部组织开发的软件包。

• People buy pack­ages that are de­ve­loped by out­side or­gan­iz­a­tions.

• 不同的系统在不同的时间构建，导致不同的技术选择。

• Dif­fer­ent sys­tems are built at dif­fer­ent times, lead­ing to dif­fer­ent tech­no­logy choices.

• 不同的系统是由不同的人构建的，他们的经验和偏好导致他们采用不同的方法来构建应用程序。

• Dif­fer­ent sys­tems are built by dif­fer­ent people whose ex­per­i­ence and pref­er­ences lead them to dif­fer­ent ap­proaches to build­ing ap­plic­a­tions.

• 推出应用程序并交付价值比确保解决集成问题更重要，尤其是当集成不会为正在开发的应用程序增加任何价值时。

• Get­ting an ap­plic­a­tion out and de­liv­er­ing value is more im­port­ant than en­sur­ing that in­teg­ra­tion is ad­dressed, es­pe­cially when that in­teg­ra­tion doesn't add any value to the ap­plic­a­tion under de­vel­op­ment.

因此，任何组织都必须担心非常不同的应用程序之间共享信息。它们可以基于不同的平台用不同的语言编写，并且对业务运作方式有不同的假设。

As a result, any or­gan­iz­a­tion has to worry about shar­ing in­form­a­tion between very di­ver­gent ap­plic­a­tions. These can be writ­ten in dif­fer­ent lan­guages, based on dif­fer­ent plat­forms, and have dif­fer­ent as­sump­tions about how the busi­ness op­er­ates.

将此类应用程序连接在一起需要彻底了解如何在业务和技术层面上将应用程序连接在一起。如果您最大限度地减少需要了解每个应用程序如何工作的信息，这会容易得多。

Tying to­gether such ap­plic­a­tions re­quires a thor­ough un­der­stand­ing of how to link to­gether ap­plic­a­tions on both the busi­ness and tech­nical levels. This is a lot easier if you min­im­ize what you need to know about how each ap­plic­a­tion works.

我们需要的是一种通用的数据传输机制，可以被多种语言和平台使用，但对每种语言和平台来说都感觉很自然。它应该需要最少量的专用硬件和软件，并利用企业现有的资源。

What is needed is a common data trans­fer mech­an­ism that can be used by a vari­ety of lan­guages and plat­forms but that feels nat­ural to each. It should re­quire a min­imal amount of spe­cial­ized hard­ware and soft­ware, making use of what the en­ter­prise already has avail­able.

文件是一种通用存储机制，内置于任何企业操作系统中，并且可通过任何企业语言使用。最简单的方法是以某种方式使用文件集成应用程序。

Files are a uni­ver­sal stor­age mech­an­ism, built into any en­ter­prise op­er­at­ing system and avail­able from any en­ter­prise lan­guage. The simplest ap­proach would be to some­how in­teg­rate the ap­plic­a­tions using files.

文件的一个重要决定是使用什么格式。一个应用程序的输出很少与另一个应用程序所需的完全一致，因此您必须在此过程中对文件进行大量处理。这意味着不仅所有使用文件的应用程序都必须读取该文件，而且您还必须能够对其使用处理工具。因此，标准文件格式随着时间的推移而不断发展。大型机系统通常使用基于 COBOL 文件系统格式的数据源。UNIX 系统使用基于文本的文件。目前的方法是使用XML。围绕这些格式建立了一个由读者、作家和转换工具组成的行业。

An im­port­ant de­cision with files is what format to use. Very rarely will the output of one ap­plic­a­tion be ex­actly what's needed for an­other, so you'll have to do a fair bit of pro­cess­ing of files along the way. This means not only that all the ap­plic­a­tions that use a file have to read it, but that you also have to be able to use pro­cess­ing tools on it. As a result, stand­ard file formats have grown up over time. Main­frame sys­tems com­monly use data feeds based on the file system formats of COBOL. UNIX sys­tems use text-based files. The cur­rent method is to use XML. An in­dustry of read­ers, writers, and trans­form­a­tion tools has built up around each of these formats.

文件的另一个问题是何时生成和使用它们。由于生成和处理文件需要一定的工作量，因此您通常不想太频繁地使用它们。通常，您有一些定期的业务周期来推动决策：每晚、每周、每季度等等。应用程序会习惯新文件何时可用并及时处理它。

An­other issue with files is when to pro­duce them and con­sume them. Since there's a cer­tain amount of effort re­quired to pro­duce and pro­cess a file, you usu­ally don't want to work with them too fre­quently. Typ­ic­ally, you have some reg­u­lar busi­ness cycle that drives the de­cision: nightly, weekly, quarterly, and so on. Ap­plic­a­tions get used to when a new file is avail­able and pro­cesses it at its time.

文件的巨大优点是集成商不需要了解应用程序的内部结构。应用团队本身通常会提供该文件。文件的内容和格式是与集成商协商的，尽管如果使用包，选择通常是有限的。然后，集成商处理其他应用程序所需的转换，或者将其留给使用应用程序来决定如何操作和读取文件。因此，不同的应用程序可以很好地相互解耦。每个应用程序都可以自由地进行内部更改，而不会影响其他应用程序，只要它们仍然以相同的格式在文件中生成相同的数据。

The great ad­vant­age of files is that in­teg­rat­ors need no know­ledge of the in­tern­als of an ap­plic­a­tion. The ap­plic­a­tion team itself usu­ally provides the file. The file's con­tents and format are ne­go­ti­ated with in­teg­rat­ors, al­though if a pack­age is used, the choices are often lim­ited. The in­teg­rat­ors then deal with the trans­form­a­tions re­quired for other ap­plic­a­tions, or they leave it up to the con­sum­ing ap­plic­a­tions to decide how they want to ma­nip­u­late and read the file. As a result, the dif­fer­ent ap­plic­a­tions are quite nicely de­coupled from each other. Each ap­plic­a­tion can make in­ternal changes freely without af­fect­ing other ap­plic­a­tions, provid­ing they still pro­duce the same data in the files in the same format. The files ef­fect­ively become the public in­ter­face of each ap­plic­a­tion.

文件传输的一部分简单的是不需要额外的工具或集成包，但这也意味着开发人员必须自己做很多工作。应用程序必须就文件命名约定及其出现的目录达成一致。文件的编写者必须实施一种策略来保持文件名的唯一性。应用程序必须就哪个文件将删除旧文件达成一致，并且负责该责任的应用程序必须知道文件何时过时且不再需要。应用程序需要实现一种锁定机制或遵循计时约定，以确保一个应用程序在另一个应用程序仍在写入文件时不会尝试读取该文件。如果所有应用程序都无法访问同一磁盘，

Part of what makes File Trans­fer simple is that no extra tools or in­teg­ra­tion pack­ages are needed, but that also means that de­ve­lopers have to do a lot of the work them­selves. The ap­plic­a­tions must agree on file-naming con­ven­tions and the dir­ect­or­ies in which they appear. The writer of a file must im­ple­ment a strategy to keep the file names unique. The ap­plic­a­tions must agree on which one will delete old files, and the ap­plic­a­tion with that re­spons­ib­il­ity will have to know when a file is old and no longer needed. The ap­plic­a­tions will need to im­ple­ment a lock­ing mech­an­ism or follow a timing con­ven­tion to ensure that one ap­plic­a­tion is not trying to read the file while an­other is still writ­ing it. If all of the ap­plic­a­tions do not have access to the same disk, then some ap­plic­a­tion must take re­spons­ib­il­ity for trans­fer­ring the file from one disk to an­other.

文件传输最明显的问题之一是更新往往很少发生，因此系统可能会不同步。客户管理系统可以处理地址变更并每晚生成提取文件，但计费系统可能会在同一天将账单发送到旧地址。有时缺乏同步并不是什么大问题。人们常常预计，即使使用计算机，获取信息也会有一定的滞后。有时，使用陈旧信息的结果是一场灾难。在决定何时生成文件时，必须考虑消费者的新鲜度需求。

One of the most ob­vi­ous issues with File Trans­fer is that up­dates tend to occur in­fre­quently, and as a result sys­tems can get out of syn­chron­iz­a­tion. A cus­tomer man­age­ment system can pro­cess a change of ad­dress and pro­duce an ex­tract file each night, but the billing system may send the bill to an old ad­dress on the same day. Some­times lack of syn­chron­iz­a­tion isn't a big deal. People often expect a cer­tain lag in get­ting in­form­a­tion around, even with com­puters. At other times the result of using stale in­form­a­tion is a dis­aster. When de­cid­ing on when to pro­duce files, you have to take the fresh­ness needs of con­sumers into ac­count.

事实上，陈旧的最大问题往往在于软件开发人员本身，他们经常必须处理不太正确的数据。这可能会导致难以解决的不一致。如果一位客户在同一天使用两个不同的系统更改了他的地址，但其中一个系统出错并获取了错误的街道名称，那么您将拥有该客户的两个不同地址。您需要某种方法来找出解决此问题的方法。文件传输之间的时间间隔越长，出现此问题的可能性就越大，也就越令人痛苦。

In fact, the biggest prob­lem with stale­ness is often on the soft­ware de­vel­op­ment staff them­selves, who fre­quently must deal with data that isn't quite right. This can lead to in­con­sist­en­cies that are dif­fi­cult to re­solve. If a cus­tomer changes his ad­dress on the same day with two dif­fer­ent sys­tems, but one of them makes an error and gets the wrong street name, you'll have two dif­fer­ent ad­dresses for a cus­tomer. You'll need some way to figure out how to re­solve this. The longer the period between file trans­fers, the more likely and more pain­ful this prob­lem can become.

当然，您没有理由不能更频繁地生成文件。事实上，您可以将消息传递视为文件传输，您可以在应用程序中的每次更改时生成一个文件。接下来的问题是管理生成的所有文件，确保它们全部被读取并且不会丢失。这超出了基于文件系统的方法的能力范围，特别是因为处理文件会产生昂贵的资源成本，如果您想快速生成大量文件，这可能会令人望而却步。因此，一旦您获得非常细粒度的文件，就更容易将它们视为消息传递。

Of course, there's no reason that you can't pro­duce files more fre­quently. Indeed, you can think of Mes­saging as File Trans­fer where you pro­duce a file with every change in an ap­plic­a­tion. The prob­lem then is man­aging all the files that get pro­duced, en­sur­ing that they are all read and that none get lost. This goes beyond what file sys­tem­based ap­proaches can do, par­tic­u­larly since there are ex­pens­ive re­source costs as­so­ci­ated with pro­cess­ing a file, which can get pro­hib­it­ive if you want to pro­duce lots of files quickly. As a result, once you get to very fine-grained files, it's easier to think of them as Mes­saging.

为了更快地提供数据并强制执行一组商定的数据格式，请使用共享数据库。要集成应用程序的功能而不是数据，请使用远程过程调用。要频繁交换少量数据（可能用于调用远程功能），请使用消息传递。

To make data avail­able more quickly and en­force an agreed-upon set of data formats, use a Shared Data­base. To in­teg­rate ap­plic­a­tions' func­tion­al­ity rather than their data, use Remote Pro­ced­ure In­voc­a­tion. To enable fre­quent ex­changes of small amounts of data, per­haps used to invoke remote func­tion­al­ity, use Mes­saging.

共享数据库

Shared Database

马丁·福勒

by Martin Fowler

一个企业有多个独立构建的应用程序，这些应用程序使用不同的语言和平台。企业需要快速、一致地共享信息。

An en­ter­prise has mul­tiple ap­plic­a­tions that are being built in­de­pend­ently, with dif­fer­ent lan­guages and plat­forms. The en­ter­prise needs in­form­a­tion to be shared rap­idly and con­sist­ently.

文件传输使如果更改不能快速通过一系列应用程序，您可能会因数据过时而犯错误。对于现代企业来说，每个人都必须拥有最新的数据。这不仅减少了错误，还增加了人们对数据本身的信任。

File Trans­fer en­ables ap­plic­a­tions to share data, but it can lack timeli­nessyet timeli­ness of in­teg­ra­tion is often crit­ical. If changes do not quickly work their way through a family of ap­plic­a­tions, you are likely to make mis­takes due to the stale­ness of the data. For modern busi­nesses, it is im­per­at­ive that every­one have the latest data. This not only re­duces errors, but also in­creases people's trust in the data itself.

快速更新还可以更好地处理不一致的情况。同步越频繁，出现不一致的可能性就越小，处理它们的工作量就越少。但无论变化多么快，仍然会出现问题。如果一个地址快速连续更新且不一致，您如何确定哪个是真实地址？您可以获取每条数据并说一个应用程序是该数据的主源，但是您必须记住哪个应用程序是哪个数据的主源。

Rapid up­dates also allow in­con­sist­en­cies to be handled better. The more fre­quently you syn­chron­ize, the less likely you are to get in­con­sist­en­cies and the less effort they are to deal with. But how­ever rapid the changes, there are still going to be prob­lems. If an ad­dress is up­dated in­con­sist­ently in rapid suc­ces­sion, how do you decide which one is the true ad­dress? You could take each piece of data and say that one ap­plic­a­tion is the master source for that data, but then you'd have to re­mem­ber which ap­plic­a­tion is the master for which data.

文件传输也集成中的许多问题都源于查看数据的方式不兼容。通常，这些代表了可能产生巨大影响的微妙业务问题。地质数据库可以将油井定义为可能产油也可能不产油的单个钻孔。生产数据库可以定义由单件设备覆盖的多个孔。这些语义不一致的情况比不一致的数据格式更难处理。（为了对这些问题进行更深入的讨论，确实值得阅读《数据与现实》[肯特].) 需要的是一个所有应用程序共享的中央一致数据存储，以便每个应用程序在需要时都可以访问任何共享数据。

File Trans­fer also may not en­force data format suf­fi­ciently. Many of the prob­lems in in­teg­ra­tion come from in­com­pat­ible ways of look­ing at the data. Often these rep­res­ent subtle busi­ness issues that can have a huge effect. A geo­lo­gical data­base may define an oil well as a single drilled hole that may or may not pro­duce oil. A pro­duc­tion data­base may define a well as mul­tiple holes covered by a single piece of equip­ment. These cases of se­mantic dis­son­ance are much harder to deal with than in­con­sist­ent data formats. (For a much deeper dis­cus­sion of these issues, it's really worth read­ing Data and Real­ity [Kent].) What is needed is a cent­ral, agreed-upon data­store that all of the ap­plic­a­tions share so each has access to any of the shared data whenever it needs it.

如果一系列集成应用程序都依赖于同一个数据库，那么您可以非常确定它们始终保持一致。如果您确实从不同来源同时更新了单个数据，那么您拥有的事务管理系统可以尽可能优雅地处理该数据。由于更新之间的时间间隔很短，因此更容易发现和修复任何错误。

If a family of in­teg­rated ap­plic­a­tions all rely on the same data­base, then you can be pretty sure that they are always con­sist­ent all of the time. If you do get sim­ul­tan­eous up­dates to a single piece of data from dif­fer­ent sources, then you have trans­ac­tion man­age­ment sys­tems that handle that about as grace­fully as it ever can be man­aged. Since the time between up­dates is so small, any errors are much easier to find and fix.

基于 SQL 的关系数据库的广泛使用使共享数据库变得更加容易。几乎所有应用程序开发平台都可以使用 SQL，通常需要使用相当复杂的工具。因此您不必担心多种文件格式。由于任何应用程序几乎都必须使用 SQL，因此这避免了添加另一种让每个人都需要掌握的技术。

Shared Data­base is made much easier by the wide­spread use of SQL-based re­la­tional data­bases. Pretty much all ap­plic­a­tion de­vel­op­ment plat­forms can work with SQL, often with quite soph­ist­ic­ated tools. So you don't have to worry about mul­tiple file formats. Since any ap­plic­a­tion pretty much has to use SQL anyway, this avoids adding yet an­other tech­no­logy for every­one to master.

由于每个应用程序都使用相同的数据库，因此这就消除了语义不一致的问题。不要让这些问题恶化，直到难以通过转换来解决，而是被迫在软件上线并收集大量不兼容数据之前面对它们并处理它们。

Since every ap­plic­a­tion is using the same data­base, this forces out prob­lems in se­mantic dis­son­ance. Rather than leav­ing these prob­lems to fester until they are dif­fi­cult to solve with trans­forms, you are forced to con­front them and deal with them before the soft­ware goes live and you col­lect large amounts of in­com­pat­ible data.

共享数据库的最大困难之一是为共享数据库提供合适的设计。提出一个可以满足多个应用程序需求的统一模式是一项非常困难的工作，通常会导致应用程序程序员难以使用该模式。如果设计统一模式的技术困难还不够，那么还存在严重的政治困难。如果关键应用程序可能会因使用统一模式而遭受延迟，那么通常会面临不可抗拒的分离压力。部门之间的人为冲突往往会加剧这个问题。

One of the biggest dif­fi­culties with Shared Data­base is coming up with a suit­able design for the shared data­base. Coming up with a uni­fied schema that can meet the needs of mul­tiple ap­plic­a­tions is a very dif­fi­cult ex­er­cise, often res­ult­ing in a schema that ap­plic­a­tion pro­gram­mers find dif­fi­cult to work with. And if the tech­nical dif­fi­culties of design­ing a uni­fied schema aren't enough, there are also severe polit­ical dif­fi­culties. If a crit­ical ap­plic­a­tion is likely to suffer delays in order to work with a uni­fied schema, then often there is ir­res­ist­ible pres­sure to sep­ar­ate. Human con­flicts between de­part­ments often ex­acer­bate this prob­lem.

对共享数据库的另一个更严格的限制是外部包。大多数打包应用程序无法使用除其自身架构之外的架构。即使有一定的适应空间，也可能比集成商希望的要有限得多。更糟糕的是，软件供应商通常保留在每个新版本的软件中更改架构的权利。

An­other, harder limit to Shared Data­base is ex­ternal pack­ages. Most pack­aged ap­plic­a­tions won't work with a schema other than their own. Even if there is some room for ad­apt­a­tion, it's likely to be much more lim­ited than in­teg­rat­ors would like. Adding to the prob­lem, soft­ware vendors usu­ally re­serve the right to change the schema with every new re­lease of the soft­ware.

这个问题还延伸到开发后的整合。即使您可以组织所有应用程序，如果发生公司合并，您仍然会遇到集成问题。

This prob­lem also ex­tends to in­teg­ra­tion after de­vel­op­ment. Even if you can or­gan­ize all your ap­plic­a­tions, you still have an in­teg­ra­tion prob­lem should a merger of com­pan­ies occur.

使用共享数据库的多个应用程序频繁读取和修改相同的数据可能会将数据库变成性能瓶颈，并且可能会导致死锁，因为每个应用程序都将其他应用程序锁定在数据之外。当应用程序分布在多个位置时，通过广域网访问单个共享数据库通常速度太慢而不实用。分布式数据库也允许每个应用程序通过本地网络连接访问数据库，但混淆了数据应该存储在哪台计算机上的问题。具有锁定冲突的分布式数据库很容易成为性能噩梦。

Mul­tiple ap­plic­a­tions using a Shared Data­base to fre­quently read and modify the same data can turn the data­base into a per­form­ance bot­tle­neck and can cause dead­locks as each ap­plic­a­tion locks others out of the data. When ap­plic­a­tions are dis­trib­uted across mul­tiple loc­a­tions, ac­cess­ing a single, shared data­base across a wide-area net­work is typ­ic­ally too slow to be prac­tical. Dis­trib­ut­ing the data­base as well allows each ap­plic­a­tion to access the data­base via a local net­work con­nec­tion, but con­fuses the issue of which com­puter the data should be stored on. A dis­trib­uted data­base with lock­ing con­flicts can easily become a per­form­ance night­mare.

要集成应用程序的功能而不是数据，请使用远程过程调用。要使用每种数据类型的格式而不是一种通用模式来频繁交换少量数据，请使用Messaging 。

To in­teg­rate ap­plic­a­tions' func­tion­al­ity rather than their data, use Remote Pro­ced­ure In­voc­a­tion. To enable fre­quent ex­changes of small amounts of data using a format per data­type rather than one uni­ver­sal schema, use Mes­saging.

远程过程调用

Remote Procedure Invocation

马丁·福勒

by Martin Fowler

一个企业有多个独立构建的应用程序，这些应用程序使用不同的语言和平台。企业需要以响应方式共享数据和流程。

An en­ter­prise has mul­tiple ap­plic­a­tions that are being built in­de­pend­ently, with dif­fer­ent lan­guages and plat­forms. The en­ter­prise needs to share data and pro­cesses in a re­spons­ive way.

文件传输和共享数据库使数据更改通常需要跨不同应用程序采取操作。例如，更改地址可能是简单的数据更改，也可能触发注册和法律程序，以考虑不同法律管辖区的不同规则。让一个应用程序直接在其他应用程序中调用此类进程将需要应用程序对其他应用程序的内部了解太多。

File Trans­fer and Shared Data­base enable ap­plic­a­tions to share their data, which is an im­port­ant part of ap­plic­a­tion in­teg­ra­tion, but just shar­ing data is often not enough. Changes in data often re­quire ac­tions to be taken across dif­fer­ent ap­plic­a­tions. For ex­ample, chan­ging an ad­dress may be a simple change in data, or it may trig­ger re­gis­tra­tion and legal pro­cesses to take into ac­count dif­fer­ent rules in dif­fer­ent legal jur­is­dic­tions. Having one ap­plic­a­tion invoke such pro­cesses dir­ectly in others would re­quire ap­plic­a­tions to know far too much about the in­tern­als of other ap­plic­a­tions.

这个问题反映了应用程序设计中的一个经典困境。应用程序设计中最强大的结构化机制之一是封装，其中模块通过函数调用接口隐藏其数据。通过这种方式，他们可以拦截数据的变化，以在数据变化时执行他们需要执行的各种操作。共享数据库提供了一个大型的、未封装的数据结构，这使得做到这一点变得更加困难。文件传输允许应用程序在处理文件时对更改做出反应，但该过程会被延迟。

This prob­lem mir­rors a clas­sic di­lemma in ap­plic­a­tion design. One of the most power­ful struc­tur­ing mech­an­isms in ap­plic­a­tion design is en­cap­su­la­tion, where mod­ules hide their data through a func­tion call in­ter­face. In this way, they can in­ter­cept changes in data to carry out the vari­ous ac­tions they need to per­form when the data is changed. Shared Data­base provides a large, un­en­cap­su­lated data struc­ture, which makes it much harder to do this. File Trans­fer allows an ap­plic­a­tion to react to changes as it pro­cesses the file, but the pro­cess is delayed.

共享数据库具有未封装的数据这一事实也使得维护一系列集成应用程序变得更加困难。任何应用程序中的许多更改都可以触发数据库中的更改，并且数据库更改会对每个应用程序产生相当大的连锁反应。因此，使用共享数据库的组织通常非常不愿意更改数据库，这意味着应用程序开发工作对业务不断变化的需求的响应能力要差得多。

The fact that Shared Data­base has un­en­cap­su­lated data also makes it more dif­fi­cult to main­tain a family of in­teg­rated ap­plic­a­tions. Many changes in any ap­plic­a­tion can trig­ger a change in the data­base, and data­base changes have a con­sid­er­able ripple effect through every ap­plic­a­tion. As a result, or­gan­iz­a­tions that use Shared Data­base are often very re­luct­ant to change the data­base, which means that the ap­plic­a­tion de­vel­op­ment work is much less re­spons­ive to the chan­ging needs of the busi­ness.

需要一种机制，让一个应用程序调用另一个应用程序中的函数，传递需要共享的数据并调用告诉接收方应用程序如何处理数据的函数。

What is needed is a mech­an­ism for one ap­plic­a­tion to invoke a func­tion in an­other ap­plic­a­tion, passing the data that needs to be shared and in­vok­ing the func­tion that tells the re­ceiver ap­plic­a­tion how to pro­cess the data.

远程过程调用将封装原则应用于集成应用程序。如果一个应用程序需要另一个应用程序拥有的某些信息，它会直接询问该应用程序。如果一个应用程序需要修改另一个应用程序的数据，它可以通过调用另一个应用程序来实现。这允许每个应用程序维护其拥有的数据的完整性。此外，每个应用程序都可以更改其内部数据的格式，而不会影响其他所有应用程序。

Remote Pro­ced­ure In­voc­a­tion ap­plies the prin­ciple of en­cap­su­la­tion to in­teg­rat­ing ap­plic­a­tions. If an ap­plic­a­tion needs some in­form­a­tion that is owned by an­other ap­plic­a­tion, it asks that ap­plic­a­tion dir­ectly. If one ap­plic­a­tion needs to modify the data of an­other, it does so by making a call to the other ap­plic­a­tion. This allows each ap­plic­a­tion to main­tain the in­teg­rity of the data it owns. Fur­ther­more, each ap­plic­a­tion can alter the format of its in­ternal data without af­fect­ing every other ap­plic­a­tion.

许多技术（例如 CORBA、COM、.NET Remoting 和 Java RMI）都实现了远程过程调用（也称为远程过程调用或 RPC）。这些方法因支持它们的系统数量及其易用性而异。这些环境通常会添加额外的功能，例如事务。由于其普遍性，当前最受欢迎的是使用 SOAP 和 XML 等标准的 Web 服务。Web 服务的一个特别有价值的特性是它们可以轻松地与 HTTP 配合使用，而 HTTP 很容易通过防火墙。

A number of tech­no­lo­gies, such as CORBA, COM, .NET Re­mot­ing, and Java RMI, im­ple­ment Remote Pro­ced­ure In­voc­a­tion (also re­ferred to as Remote Pro­ced­ure Call, or RPC). These ap­proaches vary as to how many sys­tems sup­port them and their ease of use. Often these en­vir­on­ments add ad­di­tional cap­ab­il­it­ies, such as trans­ac­tions. For sheer ubi­quity, the cur­rent fa­vor­ite is Web ser­vices, using stand­ards such as SOAP and XML. A par­tic­u­larly valu­able fea­ture of Web ser­vices is that they work easily with HTTP, which is easy to get through fire­walls.

事实上，有一些方法可以包装数据，这使得处理语义不一致变得更加容易。应用程序可以为相同的数据提供多个接口，允许某些客户端看到一种样式，而其他客户端则看到不同的样式。即使更新也可以使用多个接口。与关系视图相比，这提供了更多支持多种观点的能力。然而，集成商添加转换组件很困难，因此每个应用程序都必须与其邻居协商其接口。

The fact that there are meth­ods that wrap the data makes it easier to deal with se­mantic dis­son­ance. Ap­plic­a­tions can provide mul­tiple in­ter­faces to the same data, al­low­ing some cli­ents to see one style and others a dif­fer­ent style. Even up­dates can use mul­tiple in­ter­faces. This provides a lot more abil­ity to sup­port mul­tiple points of view than can be achieved by re­la­tional views. How­ever, it is awk­ward for in­teg­rat­ors to add trans­form­a­tion com­pon­ents, so each ap­plic­a­tion has to ne­go­ti­ate its in­ter­face with its neigh­bors.

由于软件开发人员习惯于过程调用，因此远程过程调用非常适合他们已经习惯的内容。事实上，这与其说是优点，不如说是缺点。远程和本地过程调用在性能和可靠性方面存在很大差异。如果人们不理解这些，那么远程过程调用可能会导致系统缓慢且不可靠（请参阅 [Waldo ]、[ EAA ]） 。

Since soft­ware de­ve­lopers are used to pro­ced­ure calls, Remote Pro­ced­ure In­voc­a­tion fits in nicely with what they are already used to. Ac­tu­ally, this is more of a dis­ad­vant­age than an ad­vant­age. There are big dif­fer­ences in per­form­ance and re­li­ab­il­ity between remote and local pro­ced­ure calls. If people don't un­der­stand these, then Remote Pro­ced­ure In­voc­a­tion can lead to slow and un­re­li­able sys­tems (see [Waldo], [EAA]).

尽管封装通过消除大型共享数据结构来帮助减少应用程序的耦合，但应用程序仍然相当紧密地耦合在一起。每个系统支持的远程调用往往会将不同的系统打成一个越来越大的结。特别是，按特定顺序执行某些操作可能会导致独立更改系统变得困难。之所以会出现这些类型的问题，是因为在单个应用程序中并不重要的问题在集成应用程序时变得非常重要。人们经常以设计单个应用程序的方式来设计集成，却没有意识到参与规则发生了巨大的变化。

Al­though en­cap­su­la­tion helps reduce the coup­ling of the ap­plic­a­tions by elim­in­at­ing a large shared data struc­ture, the ap­plic­a­tions are still fairly tightly coupled to­gether. The remote calls that each system sup­ports tend to tie the dif­fer­ent sys­tems into a grow­ing knot. In par­tic­u­lar, se­quen­cing­do­ing cer­tain things in a par­tic­u­lar or­der­can make it dif­fi­cult to change sys­tems in­de­pend­ently. These types of prob­lems often arise be­cause issues that aren't sig­ni­fic­ant within a single ap­plic­a­tion become so when in­teg­rat­ing ap­plic­a­tions. People often design the in­teg­ra­tion the way they would design a single ap­plic­a­tion, un­aware that the rules of the en­gage­ment change dra­mat­ic­ally.

要以更松散耦合的异步方式集成应用程序，请使用消息传递来实现少量数据的频繁交换，这些数据可能用于调用远程功能。

To in­teg­rate ap­plic­a­tions in a more loosely coupled, asyn­chron­ous fash­ion, use Mes­saging to enable fre­quent ex­changes of small amounts of data, ones that are per­haps used to invoke remote func­tion­al­ity.

消息传递

Messaging

一个企业有多个独立构建的应用程序，这些应用程序使用不同的语言和平台。企业需要以响应方式共享数据和流程。

An en­ter­prise has mul­tiple ap­plic­a­tions that are being built in­de­pend­ently, with dif­fer­ent lan­guages and plat­forms. The en­ter­prise needs to share data and pro­cesses in a re­spons­ive way.

文件传输和共享数据库使远程过程调用使通常，集成的挑战在于尽可能及时地在不同的系统之间进行协作，而不是将系统耦合在一起，以免它们在应用程序执行或应用程序开发方面变得不可靠。

File Trans­fer and Shared Data­base enable ap­plic­a­tions to share their data but not their func­tion­al­ity. Remote Pro­ced­ure In­voc­a­tion en­ables ap­plic­a­tions to share func­tion­al­ity, but it tightly couples them as well. Often the chal­lenge of in­teg­ra­tion is about making col­lab­or­a­tion between sep­ar­ate sys­tems as timely as pos­sible, without coup­ling sys­tems to­gether in such a way that they become un­re­li­able either in terms of ap­plic­a­tion ex­e­cu­tion or ap­plic­a­tion de­vel­op­ment.

文件传输允许系统无法跟上彼此的步伐。协作行为太慢了。共享数据库以响应方式将数据保存它也无法处理协作行为。

File Trans­fer allows you to keep the ap­plic­a­tions well de­coupled but at the cost of timeli­ness. Sys­tems just can't keep up with each other. Col­lab­or­at­ive be­ha­vior is way too slow. Shared Data­base keeps data to­gether in a re­spons­ive way but at the cost of coup­ling everything to the data­base. It also fails to handle col­lab­or­at­ive be­ha­vior.

面对这些问题，远程过程调用似乎是一个有吸引力的选择。但是将单一应用程序模型扩展到应用程序集成会弥补许多其他弱点。这些弱点始于分布式开发的本质问题。尽管 RPC 看起来像本地调用，但它们的行为方式并不相同。远程调用速度较慢，而且更有可能失败。当多个应用程序在企业中进行通信时，您不希望一个应用程序发生故障而导致所有其他应用程序瘫痪。此外，您不想设计一个假设调用速度很快的系统，并且您不希望每个应用程序了解其他应用程序的详细信息，

Faced with these prob­lems, Remote Pro­ced­ure In­voc­a­tion seems an ap­peal­ing choice. But ex­tend­ing a single ap­plic­a­tion model to ap­plic­a­tion in­teg­ra­tion dredges up plenty of other weak­nesses. These weak­nesses start with the es­sen­tial prob­lems of dis­trib­uted de­vel­op­ment. Des­pite that RPCs look like local calls, they don't behave the same way. Remote calls are slower, and they are much more likely to fail. With mul­tiple ap­plic­a­tions com­mu­nic­at­ing across an en­ter­prise, you don't want one ap­plic­a­tion's fail­ure to bring down all of the other ap­plic­a­tions. Also, you don't want to design a system as­sum­ing that calls are fast, and you don't want each ap­plic­a­tion know­ing the de­tails about other ap­plic­a­tions, even if it's only de­tails about their in­ter­faces.

我们需要的是像文件传输这样的东西，其中可以快速生成大量小数据包并轻松传输，并且当有新数据包可供使用时，接收器应用程序会自动收到通知。传输需要重试机制以确保其成功。用于存储数据的任何磁盘结构或数据库的详细信息都需要对应用程序隐藏，以便与共享数据库不同，可以轻松更改存储架构和详细信息以反映企业不断变化的需求。一个应用程序应该能够将数据包发送到另一个应用程序以调用另一个应用程序中的行为，例如远程过程调用，但不易失败。数据传输应该是异步的，以便发送方不需要等待接收方，特别是在需要重试时。

What we need is some­thing like File Trans­fer in which lots of little data pack­ets can be pro­duced quickly and trans­ferred easily, and the re­ceiver ap­plic­a­tion is auto­mat­ic­ally no­ti­fied when a new packet is avail­able for con­sump­tion. The trans­fer needs a retry mech­an­ism to make sure it suc­ceeds. The de­tails of any disk struc­ture or data­base for stor­ing the data needs to be hidden from the ap­plic­a­tions so that, unlike Shared Data­base, the stor­age schema and de­tails can be easily changed to re­flect the chan­ging needs of the en­ter­prise. One ap­plic­a­tion should be able to send a packet of data to an­other ap­plic­a­tion to invoke be­ha­vior in the other ap­plic­a­tion, like Remote Pro­ced­ure In­voc­a­tion, but without being prone to fail­ure. The data trans­fer should be asyn­chron­ous so that the sender does not need to wait on the re­ceiver, es­pe­cially when retry is ne­ces­sary.

异步消息传递从根本上来说是对分布式系统问题的务实反应。发送消息不需要两个系统同时启动并准备就绪。此外，以异步方式思考通信迫使开发人员认识到使用远程应用程序的速度较慢，这鼓励设计具有高内聚性（大量本地工作）和低粘附性（远程选择性工作）的组件。

Asyn­chron­ous mes­saging is fun­da­ment­ally a prag­matic re­ac­tion to the prob­lems of dis­trib­uted sys­tems. Send­ing a mes­sage does not re­quire both sys­tems to be up and ready at the same time. Fur­ther­more, think­ing about the com­mu­nic­a­tion in an asyn­chron­ous manner forces de­ve­lopers to re­cog­nize that work­ing with a remote ap­plic­a­tion is slower, which en­cour­ages design of com­pon­ents with high co­he­sion (lots of work loc­ally) and low ad­he­sion (se­lect­ive work re­motely).

消息传递系统还允许在使用文件传输时实现大部分解耦。 消息可以在传输过程中进行转换，而发送者或接收者都不知道该转换。这种解耦允许集成商在向多个接收器广播消息、将消息路由到多个接收器之一或其他拓扑之间进行选择。这将集成决策与应用程序开发分开。由于人类问题往往将应用程序开发与应用程序集成分开，因此这种方法符合人性而不是违背人性。

Mes­saging sys­tems also allow much of the de­coup­ling you get when using File Trans­fer. Mes­sages can be trans­formed in transit without either the sender or re­ceiver know­ing about the trans­form­a­tion. The de­coup­ling allows in­teg­rat­ors to choose between broad­cast­ing mes­sages to mul­tiple re­ceiv­ers, rout­ing a mes­sage to one of many re­ceiv­ers, or other to­po­lo­gies. This sep­ar­ates in­teg­ra­tion de­cisions from the de­vel­op­ment of the ap­plic­a­tions. Since human issues tend to sep­ar­ate ap­plic­a­tion de­vel­op­ment from ap­plic­a­tion in­teg­ra­tion, this ap­proach works with human nature rather than against it.

这种转换意味着不同的应用程序可以具有完全不同的概念模型。当然，这意味着会出现语义不一致。然而，消息传递的观点是，共享数据库用于避免语义不一致的措施过于复杂，无法在实践中发挥作用。此外，第三方应用程序以及作为公司合并的一部分添加的应用程序也会出现语义不一致，因此消息传递方法是解决该问题，而不是设计应用程序来避免该问题。

The trans­form­a­tion means that sep­ar­ate ap­plic­a­tions can have quite dif­fer­ent con­cep­tual models. Of course, this means that se­mantic dis­son­ance will occur. How­ever, the mes­saging view­point is that the meas­ures used by Shared Data­base to avoid se­mantic dis­son­ance are too com­plic­ated to work in prac­tice. Also, se­mantic dis­son­ance is going to occur with third-party ap­plic­a­tions and with ap­plic­a­tions added as part of a cor­por­ate merger, so the mes­saging ap­proach is to ad­dress the issue rather than design ap­plic­a­tions to avoid it.

通过频繁发送小消息，您还允许应用程序进行行为协作以及共享数据。如果收到保险索赔后需要启动流程，则可以通过在收到单个索赔时发送消息来立即完成。可以请求信息并快速做出答复。虽然这种协作不会像远程过程调用那么快，但在处理消息和返回响应时，调用者不需要停止。而且消息传递并不像许多人想象的那么慢许多消息传递解决方案起源于金融服务行业，该行业每秒有数以千计的股票报价或交易必须通过消息传递系统。

By send­ing small mes­sages fre­quently, you also allow ap­plic­a­tions to col­lab­or­ate be­ha­vi­or­ally as well as share data. If a pro­cess needs to be launched once an in­sur­ance claim is re­ceived, it can be done im­me­di­ately by send­ing a mes­sage when a single claim comes in. In­form­a­tion can be re­ques­ted and a reply made rap­idly. While such col­lab­or­a­tion isn't going to be as fast as Remote Pro­ced­ure In­voc­a­tion, the caller needn't stop while the mes­sage is being pro­cessed and the re­sponse re­turned. And mes­saging isn't as slow as many people think­many mes­saging solu­tions ori­gin­ated in the fin­an­cial ser­vices in­dustry where thou­sands of stock quotes or trades have to pass through a mes­saging system every second.

本书是关于消息传递的，因此您可以放心地假设我们认为消息传递通常是企业应用程序集成的最佳方法。但是，您不应该假设它没有问题。消息传递中消息的高频率减少了困扰文件传输的许多不一致问题，但它并没有完全删除它们。由于系统更新不完全同步，仍然会存在一些滞后问题。异步设计并不是大多数软件人员所接受的教学方式，因此存在许多不同的规则和技术。消息传递上下文使得这比在 X Windows 等异步应用程序环境中编程要容易一些，但异步仍然有一个学习曲线。在这种环境中测试和调试也更加困难。

This book is about Mes­saging, so you can safely assume that we con­sider Mes­saging to be gen­er­ally the best ap­proach to en­ter­prise ap­plic­a­tion in­teg­ra­tion. You should not assume, how­ever, that it is free of prob­lems. The high fre­quency of mes­sages in Mes­saging re­duces many of the in­con­sist­ency prob­lems that be­devil File Trans­fer, but it doesn't remove them en­tirely. There are still going to be some lag prob­lems with sys­tems not being up­dated quite sim­ul­tan­eously. Asyn­chron­ous design is not the way most soft­ware people are taught, and as a result there are many dif­fer­ent rules and tech­niques in place. The mes­saging con­text makes this a bit easier than pro­gram­ming in an asyn­chron­ous ap­plic­a­tion en­vir­on­ment like X Win­dows, but asyn­chrony still has a learn­ing curve. Test­ing and de­bug­ging are also harder in this en­vir­on­ment.

转换消息的能力有一个很好的好处，即允许应用程序彼此之间比远程过程调用更加解耦。但这种独立性确实意味着集成商通常需要编写大量混乱的粘合代码来将所有内容组合在一起。

The abil­ity to trans­form mes­sages has the nice be­ne­fit of al­low­ing ap­plic­a­tions to be much more de­coupled from each other than in Remote Pro­ced­ure In­voc­a­tion. But this in­de­pend­ence does mean that in­teg­rat­ors are often left with writ­ing a lot of messy glue code to fit everything to­gether.

一旦您决定要使用消息传递进行系统集成，就有许多新问题需要考虑和可以采用的实践。

Once you decide that you want to use Mes­saging for system in­teg­ra­tion, there are a number of new issues to con­sider and prac­tices you can employ.

如何传输数据包？

How do you trans­fer pack­ets of data?

发送方通过连接发送方和接收方的消息通道发送消息，将数据发送到接收方。

A sender sends data to a re­ceiver by send­ing a Mes­sage via a Mes­sage Chan­nel that con­nects the sender and re­ceiver.

您如何知道将数据发送到哪里？

How do you know where to send the data?

如果发送方不知道在哪里寻址数据，它可以将数据发送到消息路由器，消息路由器会将数据定向到正确的接收方。

If the sender does not know where to ad­dress the data, it can send the data to a Mes­sage Router, which will direct the data to the proper re­ceiver.

您如何知道要使用什么数据格式？

How do you know what data format to use?

如果发送方和接收方对数据格式不一致，则发送方可以将数据定向到消息转换器，将数据转换为接收方的格式，然后将数据转发到接收方。

If the sender and re­ceiver do not agree on the data format, the sender can direct the data to a Mes­sage Trans­lator that will con­vert the data to the re­ceiver's format and then for­ward the data to the re­ceiver.

如果您是应用程序开发人员，如何将应用程序连接到消息传递系统？

If you're an ap­plic­a­tion de­ve­loper, how do you con­nect your ap­plic­a­tion to the mes­saging system?

希望使用消息传递的应用程序将实现消息端点来执行实际的发送和接收。

An ap­plic­a­tion that wishes to use mes­saging will im­ple­ment Mes­sage En­d­points to per­form the actual send­ing and re­ceiv­ing.

第 3 章消息传递系统

Chapter 3. Messaging Systems

介绍

In­tro­duc­tion

留言通道

Mes­sage Chan­nel

信息

Mes­sage

管道和过滤器

Pipes and Fil­ters

消息路由器

Mes­sage Router

消息翻译器

Mes­sage Trans­lator

消息端点

Mes­sage En­d­point

介绍

Introduction

在第 2 章“集成样式”中，我们讨论了应用程序相互连接的各种选项，包括消息传递。消息传递通过异步通信使应用程序松散耦合，这也使通信更加可靠，因为两个应用程序不必同时运行。消息传递使消息传递系统负责将数据从一个应用程序传输到另一个应用程序，因此应用程序可以专注于需要共享哪些数据，而不是如何共享数据。

In Chapter 2, "In­teg­ra­tion Styles," we dis­cussed the vari­ous op­tions for con­nect­ing ap­plic­a­tions with one an­other, in­clud­ing Mes­saging. Mes­saging makes ap­plic­a­tions loosely coupled by com­mu­nic­at­ing asyn­chron­ously, which also makes the com­mu­nic­a­tion more re­li­able be­cause the two ap­plic­a­tions do not have to be run­ning at the same time. Mes­saging makes the mes­saging system re­spons­ible for trans­fer­ring data from one ap­plic­a­tion to an­other, so the ap­plic­a­tions can focus on what data they need to share as op­posed to how to share it.

基本消息传递概念

Basic Mes­saging Con­cepts

与大多数技术一样，消息传递涉及某些基本概念。一旦理解了这些概念，您甚至可以在了解有关如何使用该技术的所有细节之前就理解该技术。以下是基本消息传递概念。

Like most tech­no­lo­gies, Mes­saging in­volves cer­tain basic con­cepts. Once you un­der­stand these con­cepts, you can make sense of the tech­no­logy even before you un­der­stand all of the de­tails about how to use it. The fol­low­ing are the basic mes­saging con­cepts.

通道 消息传递应用程序通过消息通道（将发送方连接到接收方的虚拟管道）传输数据。新安装的消息系统通常不包含任何通道；您必须确定您的应用程序需要如何进行通信，然后创建通道来促进它。

消息 消息 是可以在通道上传输的原子数据包。因此，要传输数据，应用程序必须将数据分成一个或多个数据包，将每个数据包包装为一条消息，然后在通道上发送该消息。同样，接收者应用程序接收消息并且必须从消息中提取数据来处理它。消息系统将重复尝试传递消息（例如，将其从发送者传输到接收者），直到成功为止。

管道和过滤器 在 最简单的情况下，消息传递系统将消息直接从发送者的计算机传递到接收者的计算机。然而，在消息由原始发送者发送之后但在最终接收者接收之前，通常需要对消息执行某些操作。例如，由于接收方期望的消息格式与发送方的消息格式不同，因此可能必须验证或转换消息。管道和过滤器架构描述了如何使用通道将多个处理步骤链接在一起。

路由 在 具有众多应用程序和连接它们的通道的大型企业中，消息可能必须经过多个通道才能到达其最终目的地。消息必须遵循的路线可能非常复杂，以至于原始发送者不知道哪个通道会将消息发送给最终接收者。相反，原始发送者将消息发送到消息路由器，这是一个应用程序组件，它取代了管道和过滤器架构中的过滤器。然后，路由器确定如何导航通道拓扑并将消息定向到最终接收者，或至少定向到下一个路由器。

转换 不同的应用程序可能不会就相同概念数据的格式达成一致；发送方以一种方式格式化消息，但接收方希望以另一种方式格式化消息。为了协调这一点，消息必须经过中间过滤器，即消息转换器，它将消息从一种格式转换为另一种格式。

端点 大多数 应用程序没有任何与消息传递系统交互的内置功能。相反，它们必须包含一层代码，该代码层既知道应用程序如何工作，又知道消息传递系统如何工作，从而将两者联系起来，以便它们协同工作。该桥接代码是一组协调的消息端点，使应用程序能够发送和接收消息。

Chan­nels Mes­saging ap­plic­a­tions trans­mit data through a Mes­sage Chan­nel, a vir­tual pipe that con­nects a sender to a re­ceiver. A newly in­stalled mes­saging system typ­ic­ally doesn't con­tain any chan­nels; you must de­term­ine how your ap­plic­a­tions need to com­mu­nic­ate and then create the chan­nels to fa­cil­it­ate it.

Mes­sages A Mes­sage is an atomic packet of data that can be trans­mit­ted on a chan­nel. Thus, to trans­mit data, an ap­plic­a­tion must break the data into one or more pack­ets, wrap each packet as a mes­sage, and then send the mes­sage on a chan­nel. Like­wise, a re­ceiver ap­plic­a­tion re­ceives a mes­sage and must ex­tract the data from the mes­sage to pro­cess it. The mes­sage system will try re­peatedly to de­liver the mes­sage (e.g., trans­mit it from the sender to the re­ceiver) until it suc­ceeds.

Pipes and Fil­ters In the simplest case, the mes­saging system de­liv­ers a mes­sage dir­ectly from the sender's com­puter to the re­ceiver's com­puter. How­ever, cer­tain ac­tions often need to be per­formed on the mes­sage after it is sent by its ori­ginal sender but before it is re­ceived by its final re­ceiver. For ex­ample, the mes­sage may have to be val­id­ated or trans­formed be­cause the re­ceiver ex­pects a mes­sage format dif­fer­ent from the sender's. The Pipes and Fil­ters ar­chi­tec­ture de­scribes how mul­tiple pro­cess­ing steps can be chained to­gether using chan­nels.

Rout­ing In a large en­ter­prise with nu­mer­ous ap­plic­a­tions and chan­nels to con­nect them, a mes­sage may have to go through sev­eral chan­nels to reach its final des­tin­a­tion. The route a mes­sage must follow may be so com­plex that the ori­ginal sender does not know what chan­nel will get the mes­sage to the final re­ceiver. In­stead, the ori­ginal sender sends the mes­sage to a Mes­sage Router, an ap­plic­a­tion com­pon­ent that takes the place of a filter in the Pipes and Fil­ters ar­chi­tec­ture. The router then de­term­ines how to nav­ig­ate the chan­nel to­po­logy and dir­ects the mes­sage to the final re­ceiver, or at least to the next router.

Trans­form­a­tion Vari­ous ap­plic­a­tions may not agree on the format for the same con­cep­tual data; the sender formats the mes­sage one way, but the re­ceiver ex­pects it to be format­ted an­other way. To re­con­cile this, the mes­sage must go through an in­ter­me­di­ate filter, a Mes­sage Trans­lator, which con­verts the mes­sage from one format to an­other.

En­d­points Most ap­plic­a­tions do not have any built-in cap­ab­il­ity to in­ter­face with a mes­saging system. Rather, they must con­tain a layer of code that knows both how the ap­plic­a­tion works and how the mes­saging system works, bridging the two so that they work to­gether. This bridge code is a set of co­ordin­ated Mes­sage En­d­points that enable the ap­plic­a­tion to send and re­ceive mes­sages.

图书组织

Book Or­gan­iz­a­tion

本章中的模式为您提供了如何使用消息传递实现企业集成的基本词汇和理解。后续的每一章都建立在本章的基本模式之一之上，并更深入地涵盖该特定主题。

The pat­terns in this chapter provide you with the basic vocab­u­lary and un­der­stand­ing of how to achieve en­ter­prise in­teg­ra­tion using Mes­saging. Each sub­se­quent chapter builds on one of the base pat­terns in this chapter and covers that par­tic­u­lar topic in more depth.

根模式和章节的关系

Re­la­tion­ship of Root Pat­terns and Chapters

您可以直接阅读本章，以了解消息传递中主要主题的概述。有关任一主题的更多详细信息，请跳至与该特定模式相关的章节。

You can read this chapter straight through for an over­view of the main topics in Mes­saging. For more de­tails about any one of these topics, skip ahead to the chapter as­so­ci­ated with that par­tic­u­lar pat­tern.

留言通道

Message Channel

企业有两个独立的应用程序需要使用消息传递进行通信。

An en­ter­prise has two sep­ar­ate ap­plic­a­tions that need to com­mu­nic­ate by using Mes­saging.

一旦一组应用程序具有可用的消息传递系统，人们很容易认为任何应用程序都可以在您希望的任何时候与任何其他应用程序进行通信。然而，消息传递系统并不能神奇地连接所有应用程序。

Once a group of ap­plic­a­tions has a mes­saging system avail­able, it's tempt­ing to think that any ap­plic­a­tion can com­mu­nic­ate with any other ap­plic­a­tion any­time you want it to. Yet, the mes­saging system does not ma­gic­ally con­nect all of the ap­plic­a­tions.

应用程序神奇地连接

Ap­plic­a­tions Ma­gic­ally Con­nec­ted

同样，应用程序并不只是随机地将信息扔到消息传递系统中，而其他应用程序只是随机抓取它们遇到的任何信息。（即使这有效，效率也不会很高。）相反，发送信息的应用程序知道它是什么类型的信息，并且想要接收信息的应用程序不仅仅寻找任何信息，而是寻找任何信息。他们可以使用的特定类型的信息。因此，消息传递系统并不是一个供应用程序将信息放入或从中取出信息的大桶。它是一组连接，使应用程序能够通过以预定的、可预测的方式传输信息来进行通信。

Like­wise, it's not as though an ap­plic­a­tion just ran­domly throws out in­form­a­tion into the mes­saging system while other ap­plic­a­tions just ran­domly grab whatever in­form­a­tion they run across. (Even if this worked, it wouldn't be very ef­fi­cient.) Rather, the ap­plic­a­tion send­ing out the in­form­a­tion knows what sort of in­form­a­tion it is, and the ap­plic­a­tions that would like to re­ceive in­form­a­tion aren't look­ing for just any in­form­a­tion but for par­tic­u­lar types of in­form­a­tion they can use. So the mes­saging system isn't a big bucket that ap­plic­a­tions throw in­form­a­tion into and pull in­form­a­tion out of. It's a set of con­nec­tions that en­ables ap­plic­a­tions to com­mu­nic­ate by trans­mit­ting in­form­a­tion in pre­de­ter­mined, pre­dict­able ways.

当应用程序有信息需要通信时，它不仅仅将信息扔到消息传递系统中，而是将信息添加到特定的消息通道中。接收信息的应用程序并不只是从消息传递系统中随机获取信息；而是从消息传递系统中随机获取信息。它从特定的消息通道检索信息。

When an ap­plic­a­tion has in­form­a­tion to com­mu­nic­ate, it doesn't just fling the in­form­a­tion into the mes­saging system but adds the in­form­a­tion to a par­tic­u­lar Mes­sage Chan­nel. An ap­plic­a­tion re­ceiv­ing in­form­a­tion doesn't just pick it up at random from the mes­saging system; it re­trieves the in­form­a­tion from a par­tic­u­lar Mes­sage Chan­nel.

发送信息的应用程序不一定知道哪个特定应用程序最终将检索该信息，但可以确保检索该信息的应用程序对该信息感兴趣。这是因为消息系统有不同的消息通道用于应用程序想要通信的不同类型的信息。当应用程序发送信息时，它不会随机地将信息添加到任何可用的通道；它将其添加到一个通道，其特定目的是传达此类信息。同样，想要接收特定信息的应用程序不会从某个随机通道获取信息；而是会从某些随机通道中获取信息。它根据需要的信息类型选择从哪个渠道获取信息。

The ap­plic­a­tion send­ing in­form­a­tion doesn't ne­ces­sar­ily know what par­tic­u­lar ap­plic­a­tion will end up re­triev­ing it, but it can be as­sured that the ap­plic­a­tion that re­trieves the in­form­a­tion is in­ter­ested in the in­form­a­tion. This is be­cause the mes­saging system has dif­fer­ent Mes­sage Chan­nels for dif­fer­ent types of in­form­a­tion the ap­plic­a­tions want to com­mu­nic­ate. When an ap­plic­a­tion sends in­form­a­tion, it doesn't ran­domly add the in­form­a­tion to any chan­nel avail­able; it adds it to a chan­nel whose spe­cific pur­pose is to com­mu­nic­ate that sort of in­form­a­tion. Like­wise, an ap­plic­a­tion that wants to re­ceive par­tic­u­lar in­form­a­tion doesn't pull info off some random chan­nel; it se­lects what chan­nel to get in­form­a­tion from based on what type of in­form­a­tion it wants.

通道是消息系统中的逻辑地址。它们的实际实现方式取决于消息传递系统产品及其实现。也许每个消息端点都与每个其他端点有直接连接，或者它们可能都通过中央集线器连接。也许几个单独的逻辑通道被配置为一个物理通道，但仍然可以保持哪些消息要发送到哪个目的地。定义的逻辑通道集对应用程序隐藏了这些配置详细信息。

Chan­nels are lo­gical ad­dresses in the mes­saging system. How they're ac­tu­ally im­ple­men­ted de­pends on the mes­saging system product and its im­ple­ment­a­tion. Per­haps every Mes­sage En­d­point has a direct con­nec­tion to every other en­d­point, or per­haps they're all con­nec­ted through a cent­ral hub. Per­haps sev­eral sep­ar­ate lo­gical chan­nels are con­figured as one phys­ical chan­nel that nev­er­the­less keeps straight which mes­sages are in­ten­ded for which des­tin­a­tion. The set of defined lo­gical chan­nels hides these con­fig­ur­a­tion de­tails from the ap­plic­a­tions.

消息传递系统不会自动预先配置应用程序通信所需的所有消息通道。相反，设计应用程序和应用程序之间通信的开发人员必须决定他们需要什么渠道进行通信。然后，安装消息系统软件的系统管理员还必须对其进行配置，以设置应用程序期望的通道。尽管某些消息传递系统实现支持在应用程序运行时创建新通道，但这并不是很有用，因为除了创建通道的应用程序之外，其他应用程序也必须了解新通道，以便它们也可以开始使用它。因此，可用信道的数量和用途往往在部署时是固定的。第 4 章，“消息传递渠道。”）

A mes­saging system doesn't auto­mat­ic­ally come pre­con­figured with all of the mes­sage chan­nels the ap­plic­a­tions need to com­mu­nic­ate. Rather, the de­ve­lopers design­ing the ap­plic­a­tions and the com­mu­nic­a­tion between them have to decide what chan­nels they need for the com­mu­nic­a­tion. Then the system ad­min­is­trator who in­stalls the mes­saging system soft­ware must also con­fig­ure it to set up the chan­nels that the ap­plic­a­tions expect. Al­though some mes­saging system im­ple­ment­a­tions sup­port cre­at­ing new chan­nels while the ap­plic­a­tions are run­ning, this isn't very useful be­cause other ap­plic­a­tions be­sides the one that cre­ates the chan­nel must know about the new chan­nel so they can start using it too. Thus, the number and pur­pose of chan­nels avail­able tend to be fixed at de­ploy­ment time. (There are ex­cep­tions to this rule; see the in­tro­duc­tion to Chapter 4, "Mes­saging Chan­nels.")

当开发人员第一次开始使用消息系统时，经常会愚弄他们的是创建通道到底需要做什么。开发人员可以编写调用JMS API 中定义的createQueue方法的 Java 代码或包含new MessageQueue 语句的 .NET 代码，但这代码实际上都不会在消息传递系统中分配新的队列资源。相反，这些代码片段只是实例化一个运行时对象，该对象提供对已使用其管理工具在消息传递系统中创建的资源的访问。

Some­thing that often fools de­ve­lopers when they first get star­ted with using a mes­saging system is what ex­actly needs to be done to create a chan­nel. A de­ve­loper can write Java code that calls the method cre­ateQueue defined in the JMS API or .NET code that in­cludes the state­ment new Mes­sageQueue, but neither code ac­tu­ally al­loc­ates a new queue re­source in the mes­saging system. Rather, these pieces of code simply in­stan­ti­ate a runtime object that provides access to a re­source that was already cre­ated in the mes­saging system using its ad­min­is­tra­tion tools.

在设计消息传递系统的通道时，您应该记住另一个问题：通道很便宜，但它们不是免费的。应用程序需要多个通道来传输不同类型的信息以及将相同的信息传输到许多其他应用程序。每个通道都需要内存来表示消息；持久通道也需要磁盘空间。即使企业系统具有无限的内存和磁盘空间，任何消息传递系统实施通常都会对其可以一致服务的通道数量施加一些硬性或实际限制。因此，在您的应用程序需要时计划创建新通道，但如果需要数千个通道或需要以可能需要数千个通道的方式进行扩展，

There is an­other issue you should keep in mind when design­ing the chan­nels for a mes­saging system: Chan­nels are cheap, but they're not free. Ap­plic­a­tions need mul­tiple chan­nels for trans­mit­ting dif­fer­ent types of in­form­a­tion and trans­mit­ting the same in­form­a­tion to lots of other ap­plic­a­tions. Each chan­nel re­quires memory to rep­res­ent the mes­sages; per­sist­ent chan­nels re­quire disk space as well. Even if an en­ter­prise system had un­lim­ited memory and disk space, any mes­saging system im­ple­ment­a­tion usu­ally im­poses some hard or prac­tical limit to how many chan­nels it can ser­vice con­sist­ently. So plan on cre­at­ing new chan­nels as your ap­plic­a­tion needs them, but if it needs thou­sands of chan­nels or needs to scale in ways that may re­quire thou­sands of chan­nels, you'll need to choose a highly scal­able mes­saging system im­ple­ment­a­tion and test that scalab­il­ity to make sure it meets your needs.

有两种不同类型的消息通道：点对点通道和发布订阅通道。在同一通道上混合不同的数据类型可能会导致很多混乱；为了避免这种情况，请使用单独的数据类型通道。选择性消费者使一个物理通道在逻辑上像多个通道一样运作。使用消息传递的应用程序通常受益于无效消息的特殊通道，即Invalid Message Channel 。希望使用消息传递但无权访问消息传递客户端的应用程序仍然可以使用通道适配器连接到消息传递系统。一组精心设计的通道形成了消息总线，其作用类似于整组应用程序的消息传递 API。

There are two dif­fer­ent kinds of mes­sage chan­nels: Point-to-Point Chan­nels and Pub­lish-Sub­scribe Chan­nels. Mixing dif­fer­ent data types on the same chan­nel can cause a lot of con­fu­sion; to avoid this, use sep­ar­ate Data­type Chan­nels. Se­lect­ive Con­sumer makes one phys­ical chan­nel act lo­gic­ally like mul­tiple chan­nels. Ap­plic­a­tions that use mes­saging often be­ne­fit from a spe­cial chan­nel for in­valid mes­sages, an In­valid Mes­sage Chan­nel. Ap­plic­a­tions that wish to use Mes­saging but do not have access to a mes­saging client can still con­nect to the mes­saging system using Chan­nel Ad­apters. A well-de­signed set of chan­nels forms a Mes­sage Bus that acts like a mes­saging API for a whole group of ap­plic­a­tions.

j2eeadmin -addJmsDestination jms/mytopic 主题
j2eeadmin -addJmsDestination jms/myqueue 队列

j2eead­min -ad­dJms­Des­tin­a­tion jms/mytopic topic
j2eead­min -ad­dJms­Des­tin­a­tion jms/myqueue queue

上下文 jndiContext = new InitialContext();
队列 myQueue = (Queue) jndiContext.lookup("jms/myqueue");
主题 myTopic = (主题) jndiContext.lookup("jms/mytopic");

Con­text jn­diCon­text = new Ini­tial­Con­text();
Queue myQueue = (Queue) jn­diCon­text.lookup("jms/myqueue");
Topic myTopic = (Topic) jn­diCon­text.lookup("jms/mytopic");

定义 Q(myQueue)

DEFINE Q(myQueue)

Session session = // 创建会话
队列队列 = session.createQueue("myQueue");

Ses­sion ses­sion = // create the ses­sion
Queue queue = ses­sion.cre­ateQueue("myQueue");

使用系统消息传递；
...
MessageQueue.Create("MyQ​​ueue");

using System.Mes­saging;
...
Mes­sageQueue.Create("MyQueue");

MessageQueue mq = new MessageQueue("MyQ​​ueue");

Mes­sageQueue mq = new Mes­sageQueue("MyQueue");

信息

Message

企业有两个独立的应用程序，它们通过消息传递进行通信，并使用连接它们的消息通道。

An en­ter­prise has two sep­ar­ate ap­plic­a­tions that are com­mu­nic­at­ing via Mes­saging, using a Mes­sage Chan­nel that con­nects them.

消息通道通常可以被视为管道，即从一个应用程序到另一个应用程序的管道。那么，数据可以像水一样倒入一端，然后从另一端流出，这可能是合情合理的。但大多数应用程序数据并不是一个连续的流；而是一种连续的数据流。它由记录、对象、数据库行等单元组成。因此通道必须传输数据单元。

A Mes­sage Chan­nel can often be thought of as a pipe, a con­duit from one ap­plic­a­tion to an­other. It might stand to reason then that data could be poured into one end, like water, and it would come flow­ing out of the other end. But most ap­plic­a­tion data isn't one con­tinu­ous stream; it con­sists of units, such as re­cords, ob­jects, data­base rows, and the like. So a chan­nel must trans­mit units of data.

“传输”数据是什么意思？在函数调用中，调用者可以通过传递指向内存中数据地址的指针来按引用传递参数；这是有效的，因为调用者和函数共享相同的内存堆。类似地，同一进程中的两个线程可以通过传递指针来传递记录或对象，因为它们共享相同的内存空间。

What does it mean to "trans­mit" data? In a func­tion call, the caller can pass a para­meter by ref­er­ence by passing a pointer to the data's ad­dress in memory; this works be­cause both the caller and the func­tion share the same memory heap. Sim­il­arly, two threads in the same pro­cess can pass a record or object by passing a pointer, since they both share the same memory space.

传递一段数据的两个独立进程还有更多工作要做。由于它们各自有自己的内存空间，因此它们必须将数据从一个内存空间复制到另一个内存空间。数据通常以字节流的形式传输，这是最基本的数据形式。这意味着第一个进程必须将数据编组为字节形式，然后将其从第一个进程复制到第二个进程；第二个进程会将数据解组回其原始形式，以便第二个进程在第一个进程中拥有原始数据的副本。封送处理是远程过程调用 (RPC) 如何将参数发送到远程进程以及进程如何返回结果的方式。

Two sep­ar­ate pro­cesses passing a piece of data have more work to do. Since they each have their own memory space, they have to copy the data from one memory space to the other. The data is usu­ally trans­mit­ted as a byte stream, the most basic form of data. This means that the first pro­cess must mar­shal the data into byte form, and then copy it from the first pro­cess to the second one; the second pro­cess will un­mar­shal the data back into its ori­ginal form, such that the second pro­cess then has a copy of the ori­ginal data in the first pro­cess. Mar­shal­ing is how a Remote Pro­ced­ure Call (RPC) sends ar­gu­ments to the remote pro­cess and how the pro­cess re­turns the result.

因此，消息传递传输离散的数据单元，它通过对来自发送方的数据进行编组并在接收方中对其进行解组来实现这一点，以便接收方拥有自己的本地副本。有用的是一种包装数据单元的简单方法，以便适合在消息传递通道上传输数据。

So mes­saging trans­mits dis­crete units of data, and it does so by mar­shal­ing the data from the sender and un­mar­shal­ing it in the re­ceiver so that the re­ceiver has its own local copy. What would be help­ful would be a simple way to wrap a unit of data such that it is ap­pro­pri­ate to trans­mit the data on a mes­saging chan­nel.

因此，要通过消息传递系统传输的任何数据都必须转换为可以通过消息传递通道发送的一个或多个消息。

Thus, any data that is to be trans­mit­ted via a mes­saging system must be con­ver­ted into one or more mes­sages that can be sent through mes­saging chan­nels.

消息由两个基本部分组成。

A mes­sage con­sists of two basic parts.

这个概念并不是消息传递所独有的。邮政服务邮件和电子邮件都以离散邮件消息的形式发送数据。以太网以数据包的形式传输数据，TCP/IP 的 IP 部分（例如互联网）也是如此。互联网上的流媒体实际上是一系列的数据包。

This concept is not unique to mes­saging. Both postal ser­vice mail and e-mail send data as dis­crete mail mes­sages. An Eth­er­net net­work trans­mits data as pack­ets, as does the IP part of TCP/IP such as the In­ter­net. Stream­ing media on the In­ter­net is ac­tu­ally a series of pack­ets.

对于消息传递系统来说，所有消息都是相同的：如标头所描述的要传输的某些数据体。然而，对于应用程序程序员来说，存在不同类型的消息，即不同的应用程序使用风格。使用命令消息调用另一个应用程序中的过程。使用文档消息将一组数据传递到另一个应用程序。使用事件消息通知另一个应用程序此应用程序中的更改。如果其他应用程序应发回回复，请使用Request-Reply。

To the mes­saging system, all mes­sages are the same: some body of data to be trans­mit­ted as de­scribed by the header. How­ever, to the ap­plic­a­tions pro­gram­mer, there are dif­fer­ent types of mes­sagesthat is, dif­fer­ent ap­plic­a­tion styles of use. Use a Com­mand Mes­sage to invoke a pro­ced­ure in an­other ap­plic­a­tion. Use a Doc­u­ment Mes­sage to pass a set of data to an­other ap­plic­a­tion. Use an Event Mes­sage to notify an­other ap­plic­a­tion of a change in this ap­plic­a­tion. If the other ap­plic­a­tion should send back a reply, use Re­quest-Reply.

如果应用程序希望发送的信息多于一条消息所能容纳的信息，请将数据分成更小的部分并将这些部分作为消息序列发送。如果数据仅在有限的时间内有用，请将此使用时间指定为Message Expiration 。由于消息的所有不同发送者和接收者必须就消息中的数据格式达成一致，因此将格式指定为规范数据模型。

If an ap­plic­a­tion wishes to send more in­form­a­tion than one mes­sage can hold, break the data into smal­ler parts and send the parts as a Mes­sage Se­quence. If the data is only useful for a lim­ited amount of time, spe­cify this use-by time as a Mes­sage Ex­pir­a­tion. Since all the vari­ous senders and re­ceiv­ers of mes­sages must agree on the format of the data in the mes­sages, spe­cify the format as a Ca­non­ical Data Model.

[查看全宽]
<SOAP-ENV：信封
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap
/编码/“/>
   <SOAP-ENV：标头>
       <t：交易
           xmlns:t="某些 URI"
           SOAP-ENV：必须理解=“1”>
               5
       </t：交易>
   </SOAP-ENV：标头>
   <SOAP-ENV：正文>
       <m:GetLastTradePrice xmlns:m="Some-URI">
           <符号>DEF</符号>
       </m：获取最后交易价格>
   </SOAP-ENV：正文>
</SOAP-ENV：信封>

[View full width]
<SOAP-ENV:En­vel­ope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/en­vel­ope/"
  SOAP-ENV:en­cod­ing­Style="http://schemas.xmlsoap.org/soap
/en­cod­ing/"/>
   <SOAP-ENV:Header>
       <t:Trans­ac­tion
           xmlns:t="some-URI"
           SOAP-ENV:mus­tUn­der­stand="1">
               5
       </t:Trans­ac­tion>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
       <m:Get­LastTrade­Price xmlns:m="Some-URI">
           <symbol>DEF</symbol>
       </m:Get­LastTrade­Price>
   </SOAP-ENV:Body>
</SOAP-ENV:En­vel­ope>

管道和过滤器

Pipes and Filters

在许多企业集成场景中，单个事件会触发一系列处理步骤，每个处理步骤执行特定的功能。例如，假设一个新订单以消息的形式到达我们的企业。一项要求可能是对消息进行加密，以防止窃听者刺探客户的订单。第二个要求是消息包含数字证书形式的身份验证信息，以确保订单仅由受信任的客户下达。此外，外部各方可能会发送重复的消息（还记得流行购物网站上仅单击“立即订购”按钮一次的所有警告吗？）。为了避免重复发货和顾客不满意，我们需要在启动后续订单处理步骤之前消除重复的消息。为了满足这些要求，我们需要将一系列可能重复的、包含额外身份验证数据的加密消息转换为一系列唯一的、简单的纯文本订单消息，不含无关的数据字段。

In many en­ter­prise in­teg­ra­tion scen­arios, a single event trig­gers a se­quence of pro­cess­ing steps, each per­form­ing a spe­cific func­tion. For ex­ample, let's assume a new order ar­rives in our en­ter­prise in the form of a mes­sage. One re­quire­ment may be that the mes­sage is en­cryp­ted to pre­vent eaves­drop­pers from spying on a cus­tomer's order. A second re­quire­ment is that the mes­sages con­tain au­then­tic­a­tion in­form­a­tion in the form of a di­gital cer­ti­fic­ate to ensure that orders are placed only by trus­ted cus­tom­ers. In ad­di­tion, du­plic­ate mes­sages could be sent from ex­ternal parties (re­mem­ber all the warn­ings on the pop­u­lar shop­ping sites to click the Order Now button only once?). To avoid du­plic­ate ship­ments and un­happy cus­tom­ers, we need to elim­in­ate du­plic­ate mes­sages before sub­se­quent order pro­cess­ing steps are ini­ti­ated. To meet these re­quire­ments, we need to trans­form a series of pos­sibly du­plic­ated, en­cryp­ted mes­sages con­tain­ing extra au­then­tic­a­tion data into a series of unique, simple plain-text order mes­sages without the ex­traneous data fields.

一种可能的解决方案是编写一个全面的“传入消息消息处理模块”来执行所有必要的功能。然而，这种方法不灵活且难以测试。如果我们需要添加或删除步骤怎么办？例如，如果大客户可以在专用网络上下订单并且不需要加密怎么办？

One pos­sible solu­tion would be to write a com­pre­hens­ive "in­com­ing mes­sage mas­sa­ging module" that per­forms all the ne­ces­sary func­tions. How­ever, such an ap­proach would be in­flex­ible and dif­fi­cult to test. What if we need to add a step or remove one? For ex­ample, what if orders can be placed by large cus­tom­ers who are on a private net­work and do not re­quire en­cryp­tion?

在单个组件内实现所有功能也减少了重用的机会。创建更小、定义明确的组件使我们能够在其他流程中重用它们。例如，订单状态消息可以被加密，但不需要进行重复数据删除，因为重复的状态请求通常是无害的。将解密函数分离到一个单独的模块中允许我们将该函数重用于其他消息。

Im­ple­ment­ing all func­tions inside a single com­pon­ent also re­duces op­por­tun­it­ies for reuse. Cre­at­ing smal­ler, well-defined com­pon­ents allows us to reuse them in other pro­cesses. For ex­ample, order status mes­sages may be en­cryp­ted but do not need to be de-duped be­cause du­plic­ate status re­quests are gen­er­ally not harm­ful. Sep­ar­at­ing the de­cryp­tion func­tion into a sep­ar­ate module allows us to reuse this func­tion for other mes­sages.

集成解决方案通常连接一组异构系统。因此，不同的处理步骤可能需要在不同的物理机器上执行，例如当各个处理步骤只能在特定的系统上执行时。例如，出于安全原因，解密传入消息所需的私钥可能仅在指定机器上可用，并且无法从任何其他机器访问。这意味着解密组件必须在该指定机器上执行，而其他步骤可以在其他机器上执行。同样，不同的处理步骤可以使用不同的编程语言或技术来实现，从而防止它们在同一进程内运行，甚至在同一台计算机上运行。

In­teg­ra­tion solu­tions typ­ic­ally con­nect a col­lec­tion of het­ero­gen­eous sys­tems. As a result, dif­fer­ent pro­cess­ing steps may need to ex­ecute on dif­fer­ent phys­ical ma­chines, such as when in­di­vidual pro­cess­ing steps can only ex­ecute on spe­cific sys­tems. For ex­ample, it is pos­sible that the private key re­quired to de­crypt in­com­ing mes­sages is only avail­able on a des­ig­nated ma­chine and cannot be ac­cessed from any other ma­chine for se­cur­ity reas­ons. This means that the de­cryp­tion com­pon­ent has to ex­ecute on this des­ig­nated ma­chine, whereas the other steps may ex­ecute on other ma­chines. Like­wise, dif­fer­ent pro­cess­ing steps may be im­ple­men­ted using dif­fer­ent pro­gram­ming lan­guages or tech­no­lo­gies that pre­vent them from run­ning inside the same pro­cess or even on the same com­puter.

在单独的组件中实现每个功能仍然会引入组件之间的依赖关系。例如，如果解密组件用解密结果调用认证组件，那么如果没有认证函数，我们就无法使用解密函数。如果我们能够将现有组件“组合”为一系列处理步骤，使得每个组件独立于系统中的其他组件，那么我们就可以解决这些依赖性。这意味着组件公开通用外部接口，以便它们可以互换。

Im­ple­ment­ing each func­tion in a sep­ar­ate com­pon­ent can still in­tro­duce de­pend­en­cies between com­pon­ents. For ex­ample, if the de­cryp­tion com­pon­ent calls the au­then­tic­a­tion com­pon­ent with the res­ults of the de­cryp­tion, we cannot use the de­cryp­tion func­tion without the au­then­tic­a­tion func­tion. We could re­solve these de­pend­en­cies if we could "com­pose" ex­ist­ing com­pon­ents into a se­quence of pro­cess­ing steps in such a way that each com­pon­ent is in­de­pend­ent from the other com­pon­ents in the system. This would imply that com­pon­ents expose gen­eric ex­ternal in­ter­faces so that they are in­ter­change­able.

如果我们使用异步消息传递，我们应该利用从一个组件向另一个组件发送消息的异步方面。例如，一个组件可以将消息发送到另一个组件以进行进一步处理，而无需等待结果。使用这种技术，我们可以并行处理多个消息，每个组件内处理一个消息。

If we use asyn­chron­ous mes­saging, we should take ad­vant­age of the asyn­chron­ous as­pects of send­ing mes­sages from one com­pon­ent to an­other. For ex­ample, a com­pon­ent can send a mes­sage to an­other com­pon­ent for fur­ther pro­cess­ing without wait­ing for the res­ults. Using this tech­nique, we could pro­cess mul­tiple mes­sages in par­al­lel, one inside each com­pon­ent.

每个过滤器都公开一个非常简单的接口：它接收入站管道上的消息，处理消息，并将结果发布到出站管道。管道将一个过滤器连接到下一个过滤器，将输出消息从一个过滤器发送到下一个过滤器。由于所有组件都使用相同的外部接口，因此可以通过将组件连接到不同的管道来将它们组合成不同的解决方案。我们可以添加新的过滤器、省略现有的过滤器或将它们重新排列成新的序列，而无需更改过滤器本身。过滤器和管道之间的连接有时称为端口。在基本形式中，每个滤波器组件都有一个输入端口和一个输出端口。

Each filter ex­poses a very simple in­ter­face: It re­ceives mes­sages on the in­bound pipe, pro­cesses the mes­sage, and pub­lishes the res­ults to the out­bound pipe. The pipe con­nects one filter to the next, send­ing output mes­sages from one filter to the next. Be­cause all com­pon­ents use the same ex­ternal in­ter­face, they can be com­posed into dif­fer­ent solu­tions by con­nect­ing the com­pon­ents to dif­fer­ent pipes. We can add new fil­ters, omit ex­ist­ing ones, or re­ar­range them into a new se­quenceall without having to change the fil­ters them­selves. The con­nec­tion between filter and pipe is some­times called a port. In the basic form, each filter com­pon­ent has one input port and one output port.

当应用于我们的示例问题时，管道和过滤器架构会产生由两个管道连接的三个过滤器（见图）。我们需要一根额外的管道将消息发送到解密组件，还需要一根管道将明文订单消息从重复数据删除程序发送到订单管理系统。这总共有四个管道。

When ap­plied to our ex­ample prob­lem, the Pipes and Fil­ters ar­chi­tec­ture res­ults in three fil­ters con­nec­ted by two pipes (see figure). We need one ad­di­tional pipe to send mes­sages to the de­cryp­tion com­pon­ent and one to send the clear-text order mes­sages from the de-duper to the order man­age­ment system. This makes a total of four pipes.

管道和过滤器描述了消息传递系统的基本架构风格：各个处理步骤（过滤器）通过消息传递通道（管道）链接在一起。本节和后续部分中的许多模式（例如路由和转换模式）都基于此管道和过滤器架构风格。这使您可以轻松地将单个模式组合成更大的解决方案。

Pipes and Fil­ters de­scribes a fun­da­mental ar­chi­tec­tural style for mes­saging sys­tems: In­di­vidual pro­cess­ing steps (fil­ters) are chained to­gether through the mes­saging chan­nels (pipes). Many pat­terns in this and the fol­low­ing sec­tions, such as rout­ing and trans­form­a­tion pat­terns, are based on this Pipes and Fil­ters ar­chi­tec­tural style. This lets you easily com­bine in­di­vidual pat­terns into larger solu­tions.

管道和过滤器样式使用抽象管道来解耦组件。管道允许一个组件将消息发送到管道中，以便稍后可以由该组件未知的另一个进程使用该消息。这种管道的明显实现是消息通道。通常，消息通道在过滤器之间提供语言、平台和位置独立性。这使我们能够出于依赖性、维护或性能原因灵活地将处理步骤转移到不同的机器。然而，消息通道如果所有组件实际上都可以驻留在同一台机器上，那么消息传递基础设施提供的功能可能会相当重量级。使用简单的内存队列来实现管道会更加高效。因此，设计组件以便它们与抽象管道接口进行通信是很有用的。然后可以将该接口的实现换出以使用消息通道或替代实现（例如内存队列）。消息传递网关描述了如何设计组件以实现这种灵活性。

The Pipes and Fil­ters style uses ab­stract pipes to de­couple com­pon­ents from each other. The pipe allows one com­pon­ent to send a mes­sage into the pipe so that it can be con­sumed later by an­other pro­cess that is un­known to the com­pon­ent. The ob­vi­ous im­ple­ment­a­tion for such a pipe is a Mes­sage Chan­nel. Typ­ic­ally, a Mes­sage Chan­nel provides lan­guage, plat­form, and loc­a­tion in­de­pend­ence between the fil­ters. This af­fords us the flex­ib­il­ity to move a pro­cess­ing step to a dif­fer­ent ma­chine for de­pend­ency, main­ten­ance, or per­form­ance reas­ons. How­ever, a Mes­sage Chan­nel provided by a mes­saging in­fra­struc­ture can be quite heavy­weight if all com­pon­ents can in fact reside on the same ma­chine. Using a simple in-memory queue to im­ple­ment the pipes would be much more ef­fi­cient. There­fore, it is useful to design the com­pon­ents so that they com­mu­nic­ate with an ab­stract pipe in­ter­face. The im­ple­ment­a­tion of that in­ter­face can then be swapped out to use a Mes­sage Chan­nel or an al­tern­at­ive im­ple­ment­a­tion such as an in-memory queue. The Mes­saging Gate­way de­scribes how to design com­pon­ents for this flex­ib­il­ity.

管道和过滤器架构的潜在缺点之一是所需通道的数量较多。首先，通道可能不是无限的资源，因为通道提供缓冲和其他消耗内存和 CPU 周期的功能。此外，将消息发布到通道会涉及一定量的开销，因为数据必须从应用程序内部格式转换为消息传递基础结构自己的格式。在接收端，这个过程必须相反。如果我们使用长链过滤器，我们将付出灵活性的代价，但由于重复的消息数据转换，性能可能会降低。

One of the po­ten­tial down­sides of a Pipes and Fil­ters ar­chi­tec­ture is the larger number of re­quired chan­nels. First, chan­nels may not be an un­lim­ited re­source, since chan­nels provide buf­fer­ing and other func­tions that con­sume memory and CPU cycles. Also, pub­lish­ing a mes­sage to a chan­nel in­volves a cer­tain amount of over­head be­cause the data has to be trans­lated from the ap­plic­a­tion-in­ternal format into the mes­saging in­fra­struc­ture's own format. At the re­ceiv­ing end, this pro­cess has to be re­versed. If we are using a long chain of fil­ters, we are paying for the gain in flex­ib­il­ity with po­ten­tially lower per­form­ance due to re­peated mes­sage data con­ver­sion.

管道和过滤器的纯粹形式允许每个过滤器只有一个输入端口和一个输出端口。在处理消息传递时，我们可以稍微放宽这个属性。组件可以从多个通道消费消息，也可以将消息输出到多个通道（例如，消息路由器）。同样，多个过滤器组件可以使用单个消息通道的消息。点对点通道确保只有一个过滤器组件使用每条消息。

The pure form of Pipes and Fil­ters allows each filter to have only a single input port and a single output port. When deal­ing with Mes­saging, we can relax this prop­erty some­what. A com­pon­ent may con­sume mes­sages off more than one chan­nel and also output mes­sages to more than one chan­nel (for ex­ample, a Mes­sage Router). Like­wise, mul­tiple filter com­pon­ents can con­sume mes­sages off a single Mes­sage Chan­nel. A Point-to-Point Chan­nel en­sures that only one filter com­pon­ent con­sumes each mes­sage.

使用管道和过滤器还可以提高可测试性，这是一个经常被忽视的好处。我们可以通过将测试消息传递给组件并将结果消息与预期结果进行比较来测试每个单独的处理步骤。单独测试和调试每个核心功能会更有效，因为我们可以针对特定功能定制测试机制。例如，为了测试加密/解密功能，我们可以传入大量包含随机数据的消息。在加密和解密每条消息后，我们将其与原始消息进行比较。另一方面，为了测试身份验证，我们需要提供带有与系统中已知用户匹配的特定身份验证代码的消息。

Using Pipes and Fil­ters also im­proves test­abil­ity, an often over­looked be­ne­fit. We can test each in­di­vidual pro­cess­ing step by passing a Test Mes­sage to the com­pon­ent and com­par­ing the result mes­sage to the ex­pec­ted out­come. It is more ef­fi­cient to test and debug each core func­tion in isol­a­tion be­cause we can tailor the test mech­an­ism to the spe­cific func­tion. For ex­ample, to test the en­cryp­tion/de­cryp­tion func­tion we can pass in a large number of mes­sages con­tain­ing random data. After we en­crypt and de­crypt each mes­sage we com­pare it with the ori­ginal. On the other hand, to test au­then­tic­a­tion, we need to supply mes­sages with spe­cific au­then­tic­a­tion codes that match known users in the system.

流水线加工

Pipeline Pro­cess­ing

使用异步消息通道连接组件允许链中的每个单元在自己的线程或自己的进程中操作。当一个单元完成一条消息的处理后，它可以将该消息发送到输出通道并立即开始处理另一条消息。它不必等待后续组件读取并处理消息。这允许多个消息在通过各个阶段时同时进行处理。例如，在第一条消息被解密之后，它可以被传递到认证组件。与此同时，下一条消息已经可以被解密（见图）。我们将这样的配置称为处理管道因为消息流过过滤器就像液体流过管道一样。与严格的顺序处理相比，处理管道可以显着提高系统吞吐量。

Con­nect­ing com­pon­ents with asyn­chron­ous Mes­sage Chan­nels allows each unit in the chain to op­er­ate in its own thread or its own pro­cess. When a unit has com­pleted pro­cess­ing one mes­sage, it can send the mes­sage to the output chan­nel and im­me­di­ately start pro­cess­ing an­other mes­sage. It does not have to wait for the sub­se­quent com­pon­ents to read and pro­cess the mes­sage. This allows mul­tiple mes­sages to be pro­cessed con­cur­rently as they pass through the in­di­vidual stages. For ex­ample, after the first mes­sage has been de­cryp­ted, it can be passed on to the au­then­tic­a­tion com­pon­ent. At the same time, the next mes­sage can already be de­cryp­ted (see figure). We call such a con­fig­ur­a­tion a pro­cess­ing pipeline be­cause mes­sages flow through the fil­ters like liquid flows through a pipe. When com­pared to strictly se­quen­tial pro­cess­ing, a pro­cess­ing pipeline can sig­ni­fic­antly in­crease system through­put.

使用管道和过滤器进行管道处理

Pipeline Pro­cess­ing with Pipes and Fil­ters

并行处理

Par­al­lel Pro­cess­ing

然而，整体系统吞吐量受到链中最慢进程的限制。我们可以部署该流程的多个并行实例以提高吞吐量。在这种情况下，需要一个具有竞争消费者的点对点通道来保证通道上的每条消息恰好由 N 个可用处理器之一使用。这使我们能够加快最耗时的流程并提高整体吞吐量。但我们需要注意，此配置可能会导致消息处理无序。如果消息的顺序很关键，我们只能运行每个组件的一个实例，或者必须使用 Resequencer 。

How­ever, the over­all system through­put is lim­ited by the slow­est pro­cess in the chain. We can deploy mul­tiple par­al­lel in­stances of that pro­cess to im­prove through­put. In this scen­ario, a Point-to-Point Chan­nel with Com­pet­ing Con­sumers is needed to guar­an­tee that each mes­sage on the chan­nel is con­sumed by ex­actly one of N avail­able pro­cessors. This allows us to speed up the most time-in­tens­ive pro­cess and im­prove over­all through­put. We need to be aware, though, that this con­fig­ur­a­tion can cause mes­sages to be pro­cessed out of order. If the se­quence of mes­sages is crit­ical, we can run only one in­stance of each com­pon­ent or we must use a Resequen­cer.

通过并行处理提高吞吐量

In­creas­ing Through­put with Par­al­lel Pro­cess­ing

例如，如果我们假设解密消息比验证消息慢得多，则可以使用图中所示的配置，运行解密组件的三个并行实例。如果每个过滤器都是无状态的，那么并行过滤器效果最佳，也就是说，它在处理消息后返回到之前的状态。这意味着我们无法轻松运行多个并行的重复数据删除组件，因为该组件维护其已接收的所有消息的历史记录，因此不是无状态的。

For ex­ample, if we assume that de­crypt­ing a mes­sage is much slower than au­then­tic­at­ing it, we can use the con­fig­ur­a­tion shown in the figure, run­ning three par­al­lel in­stances of the de­cryp­tion com­pon­ent. Par­al­lel­iz­ing fil­ters works best if each filter is state­lessthat is, it re­turns to the pre­vi­ous state after a mes­sage has been pro­cessed. This means that we cannot easily run mul­tiple par­al­lel de-dupe com­pon­ents be­cause the com­pon­ent main­tains a his­tory of all mes­sages that it already re­ceived and is there­fore not state­less.

管道和过滤器的历史

His­tory of Pipes and Fil­ters

管道和过滤器架构绝不是一个新概念。这种架构的简单优雅与灵活性和高吞吐量相结合，使我们很容易理解管道和过滤器架构的流行。简单的语义还允许使用形式化方法来描述架构。

Pipes and Fil­ters ar­chi­tec­tures are by no means a new concept. The simple el­eg­ance of this ar­chi­tec­ture com­bined with the flex­ib­il­ity and high through­put makes it easy to un­der­stand the pop­ular­ity of Pipes and Fil­ters ar­chi­tec­tures. The simple se­mantics also allow formal meth­ods to be used to de­scribe the ar­chi­tec­ture.

[ Kahn ] 在 1974 年将 Kahn 过程网络描述为一组通过无限 FIFO（先进先出）通道连接的并行过程。[ Garlan ] 包含关于不同架构风格的好章节，包括管道和过滤器。[ Monroe ]详细论述了架构风格和设计模式之间的关系。[ PLoPD1 ] 包含 Regine Meunier 的“管道和过滤器架构”，它构成了 [ POSA ]中包含的管道和过滤器模式的基础。管道和过滤器的几乎所有与集成相关的实现遵循 [ POSA ]中提出的“场景 IV” ，使用有源过滤器独立地从队列管道拉取、处理和推送。[ POSA ]描述的模式假设每个元素在从一个过滤器传递到另一个过滤器时经历相同的处理步骤。在集成场景中通常不会出现这种情况。在许多情况下，消息是根据消息内容或外部控制动态路由的。事实上，路由在企业集成中非常常见，以至于它有自己的模式，即消息路由器。

[Kahn] de­scribed Kahn Pro­cess Net­works in 1974 as a set of par­al­lel pro­cesses that are con­nec­ted by un­boun­ded FIFO (First-In, First-Out) chan­nels. [Garlan] con­tains a good chapter on dif­fer­ent ar­chi­tec­tural styles, in­clud­ing Pipes and Fil­ters. [Monroe] gives a de­tailed treat­ment of the re­la­tion­ships between ar­chi­tec­tural styles and design pat­terns. [PLoPD1] con­tains Regine Meunier's "The Pipes and Fil­ters Ar­chi­tec­ture," which formed the basis for the Pipes and Fil­ters pat­tern in­cluded in [POSA]. Almost all in­teg­ra­tion-re­lated im­ple­ment­a­tions of Pipes and Fil­ters follow the "Scen­ario IV" presen­ted in [POSA], using active fil­ters that pull, pro­cess, and push in­de­pend­ently from and to queuing pipes. The pat­tern de­scribed by [POSA] as­sumes that each ele­ment un­der­goes the same pro­cess­ing steps as it is passed from filter to filter. This is gen­er­ally not the case in an in­teg­ra­tion scen­ario. In many in­stances, mes­sages are routed dy­nam­ic­ally based on mes­sage con­tent or ex­ternal con­trol. In fact, rout­ing is such a common oc­cur­rence in en­ter­prise in­teg­ra­tion that it war­rants its own pat­terns, the Mes­sage Router.

管道和过滤器与通信顺序进程 (CSP) 的概念有一些相似之处。由 Hoare 于 1978 年提出 [ CSP]，CSP 提供了一个简单的模型来描述并行处理系统中发生的同步问题。CSP 的基本机制是通过输入输出 (I/O) 同步两个进程。当进程 A 指示它已准备好向进程 B 输出，并且进程 B 声明它已准备好从进程 A 输入时，I/O 就会发生。如果其中一个发生而另一个不为真，则该进程将处于等待状态排队直到其他进程准备好。CSP 与集成解决方案的不同之处在于，它们不是松散耦合的，“管道”也不提供任何排队机制。尽管如此，我们还是可以从学术界对 CSP 的广泛研究中受益。

Pipes and Fil­ters share some sim­il­ar­it­ies with the concept of Com­mu­nic­at­ing Se­quen­tial Pro­cesses (CSPs). In­tro­duced by Hoare in 1978 [CSP], CSPs provide a simple model to de­scribe syn­chron­iz­a­tion prob­lems that occur in par­al­lel pro­cess­ing sys­tems. The basic mech­an­ism un­der­ly­ing CSPs is the syn­chron­iz­a­tion of two pro­cesses via input-output (I/O). I/O occurs when pro­cess A in­dic­ates that it is ready to output to pro­cess B, and pro­cess B states that it is ready to input from pro­cess A. If one of these hap­pens without the other being true, the pro­cess is put on a wait queue until the other pro­cess is ready. CSPs are dif­fer­ent from in­teg­ra­tion solu­tions in that they are not as loosely coupled, nor do the "pipes" provide any queuing mech­an­isms. Nev­er­the­less, we can be­ne­fit from the ex­tens­ive treat­ment of CSPs in the aca­demic world.

[查看全宽]
使用系统；
使用系统消息传递；

命名空间 PipesAndFilters
{
    公共类处理器
    {
        受保护的消息队列输入队列；
        受保护的消息队列输出队列；

        公共处理器（消息队列输入队列、消息队列
输出队列）
        {
            this.inputQueue = inputQueue;
            this.outputQueue = 输出队列;
        }

        公共无效进程（）
        {
            inputQueue.ReceiveCompleted += 新
ReceiveCompletedEventHandler(OnReceiveCompleted);
            inputQueue.BeginReceive();
        }

        私人无效OnReceiveCompleted（对象源，
ReceiveCompletedEventArgs asyncResult）
        {
            消息队列 mq = (消息队列)源;

            消息输入消息 = mq.EndReceive(asyncResult
.AsyncResult);
            inputMessage.Formatter = 新的 XmlMessageFormatter
                                          (new String[] {"系统
.字符串，mscorlib"});

            消息输出消息 = ProcessMessage(inputMessage);

            输出队列.Send(outputMessage);

            mq.BeginReceive();
        }

        受保护的虚拟消息ProcessMessage(Message m)
        {
            Console.WriteLine("收到消息：" + m.Body);
            返回（米）；
        }
    }
}

[View full width]
using System;
using System.Mes­saging;

namespace Pipes­And­Fil­ters
{
    public class Pro­cessor
    {
        pro­tec­ted Mes­sageQueue in­putQueue;
        pro­tec­ted Mes­sageQueue out­putQueue;

        public Pro­cessor (Mes­sageQueue in­putQueue, Mes­sageQueue
 out­putQueue)
        {
            this.in­putQueue = in­putQueue;
            this.out­putQueue = out­putQueue;
        }

        public void Pro­cess()
        {
            in­putQueue.Re­ceive­Com­pleted += new
 Re­ceive­Com­plete­dE­ventHand­ler(On­Re­ceive­Com­pleted);
            in­putQueue.Be­gin­Re­ceive();
        }

        private void On­Re­ceive­Com­pleted(Object source,
 Re­ceive­Com­plete­dEvent­Args asyn­cRes­ult)
        {
            Mes­sageQueue mq = (Mes­sageQueue)source;

            Mes­sage in­put­Mes­sage = mq.En­dRe­ceive(asyn­cRes­ult
.Asyn­cRes­ult);
            in­put­Mes­sage.Format­ter =  new Xm­lMes­sage­Format­ter
                                          (new String[] {"System
.String,mscorlib"});

            Mes­sage out­put­Mes­sage = Pro­cess­Mes­sage(in­put­Mes­sage);

            out­putQueue.Send(out­put­Mes­sage);

            mq.Be­gin­Re­ceive();
        }

        pro­tec­ted vir­tual Mes­sage Pro­cess­Mes­sage(Mes­sage m)
        {
            Con­sole.WriteLine("Re­ceived Mes­sage: " + m.Body);
            return (m);
        }
    }
}

消息路由器

Message Router

管道和过滤器链中的多个处理步骤通过消息通道连接。

Mul­tiple pro­cess­ing steps in a Pipes and Fil­ters chain are con­nec­ted by Mes­sage Chan­nels.

管道和过滤器架构风格通过固定管道将过滤器直接相互连接。这是有道理的，因为管道和过滤器模式（例如，[ POSA ] ）的许多应用程序都基于大量数据项，每个数据项都经历相同的顺序处理步骤。例如，编译器总是首先执行词法分析，其次执行语法分析，最后执行语义分析。另一方面，基于消息的集成解决方案处理不一定与单个较大数据集关联的单独消息。因此，各个消息更有可能需要一系列不同的处理步骤。

The Pipes and Fil­ters ar­chi­tec­tural style con­nects fil­ters dir­ectly to each other with fixed pipes. This makes sense be­cause many ap­plic­a­tions of the Pipes and Fil­ters pat­tern (e.g., [POSA]) are based on a large set of data items, each of which un­der­goes the same se­quen­tial pro­cess­ing steps. For ex­ample, a com­piler will always ex­ecute the lex­ical ana­lysis first, the syn­tactic ana­lysis second, and the se­mantic ana­lysis last. Mes­sage-based in­teg­ra­tion solu­tions, on the other hand, deal with in­di­vidual mes­sages that are not ne­ces­sar­ily as­so­ci­ated with a single, larger data set. As a result, in­di­vidual mes­sages are more likely to re­quire a dif­fer­ent series of pro­cess­ing steps.

消息通道将消息的发送者和接收者解耦。 这也意味着多个应用程序可以将消息发布到消息通道。因此，消息通道可以包含来自不同源的消息，这些消息可能必须根据消息的类型或其他标准进行不同的处理。您可以为每种消息类型创建一个单独的消息通道（稍后将作为数据类型通道更详细地解释这一概念））并将每个通道连接到该消息类型所需的处理步骤。然而，这将要求消息发起者了解不同处理步骤的选择标准，以便将消息发布到正确的通道。它还可能导致消息通道数量的爆炸。 此外，消息经历哪些步骤的决定可能不仅仅取决于消息的来源。例如，我们可以想象这样一种情况：消息的目的地根据迄今为止通过通道的消息数量而变化。没有任何一个发起者知道这个号码，因此无法将消息发送到正确的通道。

A Mes­sage Chan­nel de­couples the sender and the re­ceiver of a Mes­sage. This also means that mul­tiple ap­plic­a­tions can pub­lish Mes­sages to a Mes­sage Chan­nel. As a result, a Mes­sage Chan­nel can con­tain mes­sages from dif­fer­ent sources that may have to be treated dif­fer­ently based on the type of the mes­sage or other cri­teria. You could create a sep­ar­ate Mes­sage Chan­nel for each mes­sage type (a concept ex­plained in more detail later as a Data­type Chan­nel) and con­nect each chan­nel to the re­quired pro­cess­ing steps for that mes­sage type. How­ever, this would re­quire the mes­sage ori­gin­at­ors to be aware of the se­lec­tion cri­teria for dif­fer­ent pro­cess­ing steps in order to pub­lish the mes­sage to the cor­rect chan­nel. It could also lead to an ex­plo­sion of the number of Mes­sage Chan­nels. Fur­ther­more, the de­cision on which steps the mes­sage un­der­goes may not just depend on the origin of the mes­sage. For ex­ample, we could ima­gine a situ­ation where the des­tin­a­tion of a mes­sage varies de­pend­ing on the number of mes­sages that have passed through the chan­nel so far. No single ori­gin­ator would know this number and would there­fore be unable to send the mes­sage to the cor­rect chan­nel.

消息通道提供了应用程序将消息发布到消息不进一步了解该消息的目的地。因此，消息的路径可以根据订阅消息通道的组件而改变。然而，这种类型的“路由”没有考虑各个消息的属性。一旦组件订阅了消息通道，默认情况下它将消耗来自该通道的所有消息，无论单个消息的特定属性如何。此行为类似于在 UNIX 中使用管道符号来处理文本文件。它允许您将进程组成管道和过滤器链，但在链的生命周期内，所有文本行都会经历相同的步骤。

Mes­sage Chan­nels provide a very basic form of rout­ing cap­ab­il­it­ies. An ap­plic­a­tion pub­lishes a Mes­sage to a Mes­sage Chan­nel and has no fur­ther know­ledge of that Mes­sage's des­tin­a­tion. There­fore, the path of the Mes­sage can change de­pend­ing on which com­pon­ent sub­scribes to the Mes­sage Chan­nel. How­ever, this type of "rout­ing" does not take into ac­count the prop­er­ties of in­di­vidual mes­sages. Once a com­pon­ent sub­scribes to a Mes­sage Chan­nel, it will by de­fault con­sume all mes­sages from that chan­nel re­gard­less of the in­di­vidual mes­sage's spe­cific prop­er­ties. This be­ha­vior is sim­ilar to the use of the pipe symbol in UNIX to pro­cess text files. It allows you to com­pose pro­cesses into a Pipes and Fil­ters chain, but for the life­time of the chain, all lines of text un­dergo the same steps.

我们可以让接收组件本身负责确定是否应该处理到达公共消息通道的消息。但这是有问题的，因为一旦消息被使用并且组件确定它不需要该消息，它就不能只是将消息放回到通道上以供另一个组件检出。一些消息系统允许接收者在不从通道中删除消息的情况下检查消息属性，以便决定是否使用该消息。然而，这不是通用的解决方案，并且还将使用组件与特定类型的消息联系起来，因为消息选择的逻辑现在直接内置在组件中。这将降低该组件重用的可能性，并消除作为管道和过滤器模型的关键优势的可组合性。

We could make the re­ceiv­ing com­pon­ent itself re­spons­ible for de­term­in­ing whether it should pro­cess a mes­sage that ar­rives on a common Mes­sage Chan­nel. This is prob­lem­atic, though, be­cause once the mes­sage is con­sumed and the com­pon­ent de­term­ines that it does not want the mes­sage, it can't just put the mes­sage back on the chan­nel for an­other com­pon­ent to check out. Some mes­saging sys­tems allow re­ceiv­ers to in­spect mes­sage prop­er­ties without re­mov­ing the mes­sage from the chan­nel so that it can decide whether to con­sume the mes­sage. How­ever, this is not a gen­eral solu­tion and also ties the con­sum­ing com­pon­ent to a spe­cific type of mes­sage be­cause the logic for mes­sage se­lec­tion is now built right into the com­pon­ent. This would reduce the po­ten­tial for reuse of that com­pon­ent and elim­in­ate the com­pos­ab­il­ity that is the key strength of the Pipes and Fil­ters model.

许多这些替代方案都假设我们可以修改参与的组件来满足我们的需求。然而，在大多数集成解决方案中，构建块（组件）是大型应用程序，在大多数情况下根本无法修改，例如，因为它们是打包应用程序或遗留应用程序。这使得根据消息传递系统或其他应用程序的需要来调整消息生成或消费应用程序是不经济的，甚至是不可能的。

Many of these al­tern­at­ives assume that we can modify the par­ti­cip­at­ing com­pon­ents to meet our needs. In most in­teg­ra­tion solu­tions, how­ever, the build­ing blocks (com­pon­ents) are large ap­plic­a­tions that in most cases cannot be mod­i­fied at allfor ex­ample, be­cause they are pack­aged ap­plic­a­tions or legacy ap­plic­a­tions. This makes it un­eco­nom­ical or even im­pos­sible to adjust the mes­sage-pro­du­cing or -con­sum­ing ap­plic­a­tions to the needs of the mes­saging system or other ap­plic­a­tions.

管道和过滤器的优点之一是各个组件的可组合性。此属性使我们能够在过滤器链中插入额外的步骤，而无需更改现有组件。这提供了通过在两个过滤器之间插入另一个过滤器来解耦两个过滤器的选项，该过滤器确定下一步要执行的步骤。

One ad­vant­age of Pipes and Fil­ters is the com­pos­ab­il­ity of the in­di­vidual com­pon­ents. This prop­erty en­ables us to insert ad­di­tional steps into the filter chain without having to change ex­ist­ing com­pon­ents. This opens up the option of de­coup­ling two fil­ters by in­sert­ing between them an­other filter that de­term­ines what step to ex­ecute next.

消息路由器与管道和过滤器的基本概念不同，它连接到多个输出通道（即，它有多个输出端口）。然而，由于管道和过滤器架构，消息路由器周围的组件完全不知道消息路由器的存在。他们只是从一个渠道消费消息并将其发布到另一个渠道。消息路由器的一个定义属性是它不会修改消息内容；它只关心消息的目的地。

The Mes­sage Router dif­fers from the basic notion of Pipes and Fil­ters in that it con­nects to mul­tiple output chan­nels (i.e., it has more than one output port). How­ever, thanks to the Pipes and Fil­ters ar­chi­tec­ture, the com­pon­ents sur­round­ing the Mes­sage Router are com­pletely un­aware of the ex­ist­ence of a Mes­sage Router. They simply con­sume mes­sages off one chan­nel and pub­lish them to an­other. A de­fin­ing prop­erty of the Mes­sage Router is that it does not modify the mes­sage con­tents; it con­cerns itself only with the des­tin­a­tion of the mes­sage.

使用消息路由器的主要好处是消息目的地的决策标准保存在单个位置。如果定义了新的消息类型，添加了新的处理组件，或者路由规则发生了变化，我们只需要更改消息路由器逻辑，而所有其他组件不受影响。此外，由于所有消息都通过单个消息路由器，因此保证传入的消息按照正确的顺序一一处理。

The key be­ne­fit of using a Mes­sage Router is that the de­cision cri­teria for the des­tin­a­tion of a mes­sage are main­tained in a single loc­a­tion. If new mes­sage types are defined, new pro­cess­ing com­pon­ents are added, or rout­ing rules change, we need to change only the Mes­sage Router logic, while all other com­pon­ents remain un­af­fected. Also, since all mes­sages pass through a single Mes­sage Router, in­com­ing mes­sages are guar­an­teed to be pro­cessed one by one in the cor­rect order.

虽然消息路由器的目的是使过滤器彼此解耦，但使用消息路由器实际上可能会导致相反的效果。消息路由器组件必须了解所有可能的目标通道，以便将消息发送到正确的通道。如果可能的目的地列表频繁更改，消息路由器可能会成为维护瓶颈。在这些情况下，最好让各个收件人决定他们对哪些消息感兴趣。您可以通过使用发布-订阅通道和消息过滤器数组来实现此目的。我们通过称为预测路由和反应式过滤来对比这两种替代方案（有关更详细的比较，请参阅第 7消息章路由”中的消息过滤器）。

While the intent of a Mes­sage Router is to de­couple fil­ters from each other, using a Mes­sage Router can ac­tu­ally cause the op­pos­ite effect. The Mes­sage Router com­pon­ent must have know­ledge of all pos­sible des­tin­a­tion chan­nels in order to send the mes­sage to the cor­rect chan­nel. If the list of pos­sible des­tin­a­tions changes fre­quently, the Mes­sage Router can turn into a main­ten­ance bot­tle­neck. In those cases, it would be better to let the in­di­vidual re­cip­i­ents decide which mes­sages they are in­ter­ested in. You can ac­com­plish this by using a Pub­lish-Sub­scribe Chan­nel and an array of Mes­sage Fil­ters. We con­trast these two al­tern­at­ives by call­ing them pre­dict­ive rout­ing and re­act­ive fil­ter­ing (for a more de­tailed com­par­ison, see the Mes­sage Filter in Chapter 7, "Mes­sage Rout­ing").

由于消息路由器需要插入额外的处理步骤，因此可能会降低性能。许多基于消息的系统必须先对来自一个通道的消息进行解码，然后才能将其放置到另一通道上，如果消息本身没有真正改变，这会导致计算开销。这种开销可能会将消息路由器变成性能瓶颈。通过并行使用多个路由器或添加额外的硬件，可以最大限度地减少这种影响。因此，消息吞吐量（每时间单位处理的消息数量）可能不会受到影响，但延迟（一条消息通过系统的时间）几乎肯定会增加。

Be­cause a Mes­sage Router re­quires the in­ser­tion of an ad­di­tional pro­cess­ing step, it can de­grade per­form­ance. Many mes­sage-based sys­tems have to decode the mes­sage from one chan­nel before it can be placed on an­other chan­nel, which causes com­pu­ta­tional over­head if the mes­sage itself does not really change. This over­head can turn a Mes­sage Router into a per­form­ance bot­tle­neck. By using mul­tiple routers in par­al­lel or adding ad­di­tional hard­ware, this effect can be min­im­ized. As a result, the mes­sage through­put (number of mes­sages pro­cessed per time unit) may not be im­pacted, but the latency (time for one mes­sage to travel through the system) will almost cer­tainly in­crease.

与大多数优秀工具一样，消息路由器也可能被滥用。故意使用消息路由器可能会将松散耦合的优点变成缺点。松散耦合的系统可能会导致难以理解解决方案的“大局”（即通过系统的整体消息流）。这是消息传递解决方案的常见问题，而使用路由器可能会加剧该问题。如果一切都与其他一切松散耦合，那么就不可能理解消息实际流向的方向。这会使测试、调试和维护变得复杂。许多工具可以帮助缓解这个问题。首先，我们可以使用消息历史记录在运行时检查消息并查看它们遍历了哪些组件。或者，我们可以编译系统中每个组件订阅或发布的所有通道的列表。有了这些知识，我们就可以绘制跨组件的所有可能消息流的图表。许多 EAI 包在中央存储库中维护频道订阅信息，使这种类型的静态分析变得更加容易。

Like most good tools, Mes­sage Routers can also be abused. De­lib­er­ate use of Mes­sage Routers can turn the ad­vant­age of loose coup­ling into a dis­ad­vant­age. Loosely coupled sys­tems can make it dif­fi­cult to un­der­stand the "big pic­ture" of the solu­tionthe over­all flow of mes­sages through the system. This is a common prob­lem with mes­saging solu­tions, and the use of routers can ex­acer­bate the prob­lem. If everything is loosely coupled to everything else, it be­comes im­pos­sible to un­der­stand in which dir­ec­tion mes­sages ac­tu­ally flow. This can com­plic­ate test­ing, de­bug­ging, and main­ten­ance. A number of tools can help al­le­vi­ate this prob­lem. First, we can use the Mes­sage His­tory to in­spect mes­sages at runtime and see which com­pon­ents they tra­versed. Al­tern­at­ively, we can com­pile a list of all chan­nels to which each com­pon­ent in the system sub­scribes or pub­lishes. With this know­ledge we can draw a graph of all pos­sible mes­sage flows across com­pon­ents. Many EAI pack­ages main­tain chan­nel sub­scrip­tion in­form­a­tion in a cent­ral re­pos­it­ory, making this type of static ana­lysis easier.

消息路由器变体

Mes­sage Router Vari­ants

消息路由器可以使用任意数量的标准来确定传入消息的输出通道。最简单的情况是固定路由器。在这种情况下，仅定义单个输入通道和单个输出通道。固定路由器从输入通道消耗一条消息并将其发布到输出通道。为什么我们要使用这样一个无脑的路由器？固定路由器可能有助于有意解耦子系统，以便我们稍后可以插入更智能的路由器。或者，我们可能在多个集成解决方案之间中继消息。在大多数情况下，固定路由器将与消息转换器或通道适配器结合使用转换消息内容或通过不同的通道类型发送消息。

A Mes­sage Router can use any number of cri­teria to de­term­ine the output chan­nel for an in­com­ing mes­sage. The most trivial case is a fixed router. In this case, only a single input chan­nel and a single output chan­nel are defined. The fixed router con­sumes one mes­sage off the input chan­nel and pub­lishes it to the output chan­nel. Why would we ever use such a brain­less router? A fixed router may be useful to in­ten­tion­ally de­couple sub­sys­tems so that we can insert a more in­tel­li­gent router later. Or, we may be re­lay­ing mes­sages between mul­tiple in­teg­ra­tion solu­tions. In most cases, a fixed router will be com­bined with a Mes­sage Trans­lator or a Chan­nel Ad­apter to trans­form the mes­sage con­tent or send the mes­sage over a dif­fer­ent chan­nel type.

许多消息路由器仅根据消息本身的属性来决定消息目的地，例如消息类型或特定消息字段的值。我们将这样的路由器称为基于内容的路由器。这种类型的路由器非常常见，因此基于内容的路由器模式对其进行了更详细的描述。

Many Mes­sage Routers decide the mes­sage des­tin­a­tion only on prop­er­ties of the mes­sage it­self­for ex­ample, the mes­sage type or the values of spe­cific mes­sage fields. We call such a router a Con­tent-Based Router. This type of router is so common that the Con­tent-Based Router pat­tern de­scribes it in more detail.

其他消息路由器根据环境条件决定消息的目的地。我们将这些路由器称为基于上下文的路由器。此类路由器通常用于执行负载平衡、测试或故障转移功能。例如，如果处理组件发生故障，基于上下文的路由器可以将消息重新路由到另一个处理组件，从而提供故障转移能力。其他路由器将消息流均匀地分配到多个通道，以实现类似于负载均衡器的并行处理。一些消息通道已经提供了基本的负载平衡功能，而无需使用消息路由器，因为多个竞争消费者每个人都可以尽可能快地从同一通道消费消息。但是，消息路由器可以具有额外的内置智能来路由消息，而不是通道实现的简单循环。

Other Mes­sage Routers decide the mes­sage's des­tin­a­tion based on en­vir­on­ment con­di­tions. We call these routers con­text-based routers. Such routers are com­monly used to per­form load-bal­an­cing, test, or fail­over func­tion­al­ity. For ex­ample, if a pro­cess­ing com­pon­ent fails, the con­text-based router can reroute mes­sages to an­other pro­cess­ing com­pon­ent and thus provide fail­over cap­ab­il­ity. Other routers split the flow of mes­sages evenly across mul­tiple chan­nels to achieve par­al­lel pro­cess­ing sim­ilar to a load bal­an­cer. Some Mes­sage Chan­nels already provide basic load-bal­an­cing cap­ab­il­it­ies without the use of a Mes­sage Router be­cause mul­tiple Com­pet­ing Con­sumers can each con­sume mes­sages off the same chan­nel as fast as they can. How­ever, a Mes­sage Router can have ad­di­tional built-in in­tel­li­gence to route the mes­sages as op­posed to a simple round-robin im­ple­men­ted by the chan­nel.

换句话说，许多消息路由器是无状态的，它们一次只查看一条消息来做出路由决策。其他路由器在做出路由决策时会考虑先前消息的内容。例如，管道和过滤器示例使用的路由器通过保留已接收到的所有消息的列表来消除重复消息。这些路由器是有状态的。

Many Mes­sage Routers are state­lessin other words, they look at only one mes­sage at a time to make the rout­ing de­cision. Other routers take the con­tent of pre­vi­ous mes­sages into ac­count when making a rout­ing de­cision. For ex­ample, the Pipes and Fil­ters ex­ample used a router that elim­in­ates du­plic­ate mes­sages by keep­ing a list of all mes­sages it already re­ceived. These routers are state­ful.

大多数消息路由器包含用于路由决策的硬编码逻辑。但是，某些变体连接到控制总线，以便中间件解决方案可以更改决策标准，而无需进行任何代码更改或中断消息流。例如，控制总线可以将全局变量的值传播到系统中的所有消息路由器。这对于允许消息系统从测试模式切换到生产模式的测试非常有用。动态路由器根据来自每个潜在接收者的控制消息动态地配置自身。

Most Mes­sage Routers con­tain hard-coded logic for the rout­ing de­cision. How­ever, some vari­ants con­nect to a Con­trol Bus so that the mid­dle­ware solu­tion can change the de­cision cri­teria without having to make any code changes or in­ter­rupt­ing the flow of mes­sages. For ex­ample, the Con­trol Bus can propag­ate the value of a global vari­able to all Mes­sage Routers in the system. This can be very useful for test­ing to allow the mes­saging system to switch from test to pro­duc­tion mode. The Dy­namic Router con­fig­ures itself dy­nam­ic­ally based on con­trol mes­sages from each po­ten­tial re­cip­i­ent.

第 7 章“消息路由”介绍了消息路由器的更多变体。

Chapter 7, "Mes­sage Rout­ing," in­tro­duces more vari­ants of the Mes­sage Router.

[查看全宽]
简单路由器类
{
    受保护的消息队列inQueue；
    受保护的消息队列outQueue1；
    受保护的消息队列outQueue2；

    公共 SimpleRouter(消息队列 inQueue, 消息队列
输出队列1、消息队列输出队列2)
    {
        this.inQueue = inQueue;
        this.outQueue1 = outQueue1;
        this.outQueue2 = outQueue2;

        inQueue.ReceiveCompleted += 新
ReceiveCompletedEventHandler(OnMessage);
        inQueue.BeginReceive();
    }
    私有无效OnMessage（对象源，
ReceiveCompletedEventArgs asyncResult）
    {
        消息队列 mq = (消息队列)源;
        消息消息 = mq.EndReceive(asyncResult.AsyncResult);

        if (IsConditionFulfilled())
            outQueue1.Send(消息);
        别的
            outQueue2.Send(消息);

        mq.BeginReceive();
    }

    受保护的布尔切换= false；

    protected bool IsConditionFulfilled ()
    {
        切换=！切换；
        返回切换；
    }

}

[View full width]
class Sim­pleRouter
{
    pro­tec­ted Mes­sageQueue in­Queue;
    pro­tec­ted Mes­sageQueue out­Queue1;
    pro­tec­ted Mes­sageQueue out­Queue2;

    public Sim­pleRouter(Mes­sageQueue in­Queue, Mes­sageQueue
 out­Queue1, Mes­sageQueue out­Queue2)
    {
        this.in­Queue = in­Queue;
        this.out­Queue1 = out­Queue1;
        this.out­Queue2 = out­Queue2;

        in­Queue.Re­ceive­Com­pleted += new
 Re­ceive­Com­plete­dE­ventHand­ler(On­Mes­sage);
        in­Queue.Be­gin­Re­ceive();
    }
    private void On­Mes­sage(Object source,
 Re­ceive­Com­plete­dEvent­Args asyn­cRes­ult)
    {
        Mes­sageQueue mq = (Mes­sageQueue)source;
        Mes­sage mes­sage = mq.En­dRe­ceive(asyn­cRes­ult.Asyn­cRes­ult);

        if (IsCon­di­tion­Ful­filled())
            out­Queue1.Send(mes­sage);
        else
            out­Queue2.Send(mes­sage);

        mq.Be­gin­Re­ceive();
    }

    pro­tec­ted bool toggle = false;

    pro­tec­ted bool IsCon­di­tion­Ful­filled ()
    {
        toggle = !toggle;
        return toggle;
    }

}

消息翻译器

Message Translator

前面的模式展示了如何构造消息以及如何将它们路由到正确的目的地。在许多情况下，企业集成解决方案在现有应用程序（例如遗留系统、打包应用程序、自行开发的自定义应用程序或外部合作伙伴运营的应用程序）之间路由消息。这些应用程序中的每一个通常都是围绕专有数据模型构建的。每个应用程序对客户实体、定义客户的属性以及与客户相关的其他实体的概念可能略有不同。例如，会计系统可能对客户的纳税人 ID 号更感兴趣，而客户关系管理 (CRM) 系统则存储电话号码和地址。应用程序的底层数据模型通常驱动物理数据库模式、接口文件格式或应用程序编程接口 (API) 的设计，这些实体是集成解决方案必须与之交互的实体。因此，每个应用程序通常期望接收模仿应用程序内部数据格式的消息。

The pre­vi­ous pat­terns show how to con­struct mes­sages and how to route them to the cor­rect des­tin­a­tion. In many cases, en­ter­prise in­teg­ra­tion solu­tions route mes­sages between ex­ist­ing ap­plic­a­tions such as legacy sys­tems, pack­aged ap­plic­a­tions, homegrown custom ap­plic­a­tions, or ap­plic­a­tions op­er­ated by ex­ternal part­ners. Each of these ap­plic­a­tions is usu­ally built around a pro­pri­et­ary data model. Each ap­plic­a­tion may have a slightly dif­fer­ent notion of the Cus­tomer entity, the at­trib­utes that define a Cus­tomer, and other en­tit­ies to which a Cus­tomer is re­lated. For ex­ample, the ac­count­ing system may be more in­ter­ested in the cus­tomer's tax­payer ID num­bers, whereas the cus­tomer-re­la­tion­ship man­age­ment (CRM) system stores phone num­bers and ad­dresses. The ap­plic­a­tion's un­der­ly­ing data model usu­ally drives the design of the phys­ical data­base schema, an in­ter­face file format, or an ap­plic­a­tion pro­gram­ming in­ter­face (API)those en­tit­ies with which an in­teg­ra­tion solu­tion must in­ter­face. As a result, each ap­plic­a­tion typ­ic­ally ex­pects to re­ceive mes­sages that mimic the ap­plic­a­tion's in­ternal data format.

除了各种应用程序中包含的专有数据模型和数据格式之外，集成解决方案通常还通过独立于特定应用程序的标准化数据格式与外部业务合作伙伴进行交互。许多联盟和标准机构定义了这些协议；例如，RosettaNet、ebXML、OAGIS 和许多其他特定行业联盟。在许多情况下，集成解决方案需要能够使用“官方”数据格式与外部各方进行通信，即使内部系统基于专有格式。

In ad­di­tion to the pro­pri­et­ary data models and data formats in­cor­por­ated in the vari­ous ap­plic­a­tions, in­teg­ra­tion solu­tions often in­ter­act with ex­ternal busi­ness part­ners via stand­ard­ized data formats that are in­de­pend­ent from spe­cific ap­plic­a­tions. A number of con­sor­tia and stand­ards bodies define these pro­to­cols; for ex­ample, Roset­taNet, ebXML, OAGIS, and many other in­dustry-spe­cific con­sor­tia. In many cases, the in­teg­ra­tion solu­tion needs to be able to com­mu­nic­ate with ex­ternal parties using the "of­fi­cial" data formats, even though the in­ternal sys­tems are based on pro­pri­et­ary formats.

如果我们可以修改所有应用程序以使用通用数据格式，我们就可以避免转换消息。由于多种原因，这变得很困难（请参阅共享数据库）。首先，更改应用程序的数据格式是有风险的、困难的，并且需要对固有业务功能进行大量更改。对于大多数遗留应用程序来说，更改数据格式在经济上根本不可行。我们可能都记得与 Y2K 改造相关的工作，其中更改的范围仅限于单个字段的大小！

We could avoid having to trans­form mes­sages if we could modify all ap­plic­a­tions to use a common data format. This turns out to be dif­fi­cult for a number of reas­ons (see Shared Data­base). First, chan­ging an ap­plic­a­tion's data format is risky, dif­fi­cult, and re­quires a lot of changes to in­her­ent busi­ness func­tion­al­ity. For most legacy ap­plic­a­tions, data format changes are simply not eco­nom­ic­ally feas­ible. We may all re­mem­ber the effort re­lated to the Y2K ret­ro­fits, where the scope of the change was lim­ited to the size of a single field!

此外，虽然我们可能会让多个应用程序使用相同的数据字段名称甚至相同的数据类型，但物理表示可能仍然有很大不同。一个应用程序可能使用 XML 文档，而另一个应用程序则使用 COBOL copybook。

Also, while we may get mul­tiple ap­plic­a­tions to use the same data field names and maybe even the same data types, the phys­ical rep­res­ent­a­tion may still be quite dif­fer­ent. One ap­plic­a­tion may use XML doc­u­ments, whereas the other ap­plic­a­tion uses COBOL copy­books.

此外，如果我们调整一个应用程序的数据格式以匹配另一应用程序的数据格式，我们就会将这两个应用程序彼此更紧密地联系在一起。企业集成的关键架构原则之一是应用程序之间的松耦合（请参阅规范数据模型）。修改一个应用程序以匹配另一个应用程序的数据格式将违反这一原则，因为它使两个应用程序直接依赖于彼此的内部表示。这消除了替换或更改一个应用程序而不影响另一个应用程序的可能性，这种情况在企业集成中相当常见。

Fur­ther­more, if we adjust the data format of one ap­plic­a­tion to match that of an­other ap­plic­a­tion, we are tying the two ap­plic­a­tions more tightly to each other. One of the key ar­chi­tec­tural prin­ciples in en­ter­prise in­teg­ra­tion is loose coup­ling between ap­plic­a­tions (see Ca­non­ical Data Model). Modi­fy­ing one ap­plic­a­tion to match an­other ap­plic­a­tion's data format would vi­ol­ate this prin­ciple be­cause it makes two ap­plic­a­tions dir­ectly de­pend­ent on each other's in­ternal rep­res­ent­a­tion. This elim­in­ates the pos­sib­il­ity of re­pla­cing or chan­ging one ap­plic­a­tion without af­fect­ing the other ap­plic­a­tion, a scen­ario that is fairly common in en­ter­prise in­teg­ra­tion.

我们可以将数据格式转换直接合并到消息端点中。这样，所有应用程序都将以通用格式而不是应用程序的内部数据格式发布和使用消息。然而，这种方法需要访问端点代码，而打包应用程序通常不是这种情况。此外，将格式转换硬编码到端点将减少代码重用的机会。

We could in­cor­por­ate the data format trans­la­tion dir­ectly into the Mes­sage En­d­point. This way, all ap­plic­a­tions would pub­lish and con­sume mes­sages in a common format as op­posed to in the ap­plic­a­tion's in­ternal data format. How­ever, this ap­proach re­quires access to the en­d­point code, which is usu­ally not the case for pack­aged ap­plic­a­tions. In ad­di­tion, hard-coding the format trans­la­tion to the en­d­point would reduce the op­por­tun­it­ies for code reuse.

消息转换器是[GoF] 中描述的适配器模式的消息传递等效项。 适配器将组件的接口转换为另一个接口，以便它可以在不同的上下文中使用。

The Mes­sage Trans­lator is the mes­saging equi­val­ent of the Ad­apter pat­tern de­scribed in [GoF]. An ad­apter con­verts the in­ter­face of a com­pon­ent into an­other in­ter­face so it can be used in a dif­fer­ent con­text.

转型水平

Levels of Trans­form­a­tion

消息翻译可能需要在许多不同的级别上进行。例如，数据元素可以共享相同的名称和数据类型，但可以以不同的表示形式使用（例如，XML 文件与逗号分隔值与固定长度字段）。或者，所有数据元素都可以以 XML 格式表示，但使用不同的标签名称。为了总结不同类型的翻译，我们可以将其分为多个层（大致借用 OSI 参考模型）。

Mes­sage trans­la­tion may need to occur at a number of dif­fer­ent levels. For ex­ample, data ele­ments may share the same name and data types but may be used in dif­fer­ent rep­res­ent­a­tions (e.g., XML file vs. comma-sep­ar­ated values vs. fixed-length fields). Or, all data ele­ments may be rep­res­en­ted in XML format but use dif­fer­ent tag names. To sum­mar­ize the dif­fer­ent kinds of trans­la­tion, we can divide it into mul­tiple layers (loosely bor­row­ing from the OSI Ref­er­ence Model).

“堆栈”底部的传输层提供不同系统之间的数据传输。它负责跨不同网段的完整可靠的数据传输，并处理丢失的数据包和其他网络错误。一些EAI 供应商提供自己的传输协议（例如TIBCO RendezVous），而其他集成技术则利用TCP/IP 协议（​​例如SOAP）。不同传输层之间的转换可以由通道适配器模式提供。

The Trans­port layer at the bottom of the "stack" provides data trans­fer between the dif­fer­ent sys­tems. It is re­spons­ible for com­plete and re­li­able data trans­fer across dif­fer­ent net­work seg­ments and deals with lost data pack­ets and other net­work errors. Some EAI vendors provide their own trans­port pro­to­cols (e.g., TIBCO Ren­dez­Vous), whereas other in­teg­ra­tion tech­no­lo­gies lever­age TCP/IP pro­to­cols (e.g., SOAP). Trans­la­tion between dif­fer­ent trans­port layers can be provided by the Chan­nel Ad­apter pat­tern.

数据表示层也称为语法层。该层定义了传输的数据的表示。这种转换是必要的，因为传输层通常只传输字符或字节流。这意味着复杂的数据结构必须转换为字符串。此转换的常见格式包括 XML、固定长度字段（例如 EDI 记录）和专有格式。在许多情况下，数据也被压缩或加密并带有校验位或数字证书。为了与具有不同数据表示形式的系统进行接口，可能必须对数据进行解密、解压缩和解析，然后必须呈现新的数据格式，并且还可能进行压缩和加密。

The Data Rep­res­ent­a­tion layer is also re­ferred to as the syntax layer. This layer defines the rep­res­ent­a­tion of data that is trans­por­ted. This trans­la­tion is ne­ces­sary be­cause the trans­port layer typ­ic­ally trans­ports only char­ac­ter or byte streams. This means that com­plex data struc­tures have to be con­ver­ted into a char­ac­ter string. Common formats for this con­ver­sion in­clude XML, fixed-length fields (e.g., EDI re­cords), and pro­pri­et­ary formats. In many cases, data is also com­pressed or en­cryp­ted and car­ries check digits or di­gital cer­ti­fic­ates. In order to in­ter­face sys­tems with dif­fer­ent data rep­res­ent­a­tions, data may have to be de­cryp­ted, un­com­pressed, and parsed, and then the new data format must be rendered and pos­sibly com­pressed and en­cryp­ted as well.

数据类型层定义应用程序（域）模型所基于的应用程序数据类型。在这里，我们处理诸如日期字段是否表示为字符串或本机日期结构、日期是否带有时间组件、它们基于哪个时区等决策。我们还可以考虑邮政编码字段是否仅表示美国邮政编码或可以包含加拿大邮政编码。如果是美国邮政编码，是否包含 ZIP+4？是强制性的吗？它存储在一个字段中还是两个字段中？其中许多问题通常在所谓的数据字典中得到解决。与数据类型相关的问题超出了字段是字符串类型还是整数类型的范围。考虑按地区组织的销售数据。一个部门使用的应用程序可以将国家分为四个区域：西部、中部、南部和东部，用字母 W、C、S 和 E 标识。另一个部门可以区分太平洋地区和山区，并区分太平洋地区和山区。从东南向东北。每个区域都由一个两位数的数字来标识。字母E对应什么数字？

The Data Types layer defines the ap­plic­a­tion data types on which the ap­plic­a­tion (domain) model is based. Here we deal with such de­cisions as whether date fields are rep­res­en­ted as strings or as native date struc­tures, whether dates carry a time-of-day com­pon­ent, which time zone they are based on, and so on. We may also con­sider whether the field Postal Code de­notes only a U.S. ZIP code or can con­tain Ca­na­dian postal codes. In the case of a U.S. zip code, do we in­clude a ZIP+4? Is it man­dat­ory? Is it stored in one field, or two? Many of these ques­tions are usu­ally ad­dressed in so-called Data Dic­tion­ar­ies. The issues re­lated to data types go beyond whether a field is of type string or in­teger. Con­sider sales data that is or­gan­ized by region. The ap­plic­a­tion used by one de­part­ment may divide the coun­try into four re­gions: West, Cent­ral, South, and East, iden­ti­fied by the let­ters W, C, S, and E. An­other de­part­ment may dif­fer­en­ti­ate the Pa­cific region from the moun­tain region and dis­tin­guish the North­east from the South­east. Each region is iden­ti­fied by a two-digit number. What number does the letter E cor­res­pond to?

数据结构层描述应用程序域模型级别的数据。因此也称为应用层。该层定义应用程序处理的逻辑实体，例如客户、地址或帐户。它还定义了这些实体之间的关系：一个客户可以拥有多个帐户吗？一个客户可以有多个地址吗？客户可以分享地址吗？多个客户可以共用一个账户吗？地址是帐户还是客户的一部分？这是实体关系图和类图的领域。

The Data Struc­tures layer de­scribes the data at the level of the ap­plic­a­tion domain model. It is there­fore also re­ferred to as the ap­plic­a­tion layer. This layer defines the lo­gical en­tit­ies that the ap­plic­a­tion deals with, such as cus­tomer, ad­dress, or ac­count. It also defines the re­la­tion­ships between these en­tit­ies: Can one cus­tomer have mul­tiple ac­counts? Can a cus­tomer have mul­tiple ad­dresses? Can cus­tom­ers share an ad­dress? Can mul­tiple cus­tom­ers share an ac­count? Is the ad­dress part of the ac­count or the cus­tomer? This is the domain of entity-re­la­tion­ship dia­grams and class dia­grams.

解耦的程度

Levels of De­coup­ling

集成中的许多设计权衡都是由解耦组件或应用程序的需要驱动的。解耦是实现变革管理的重要工具。集成通常连接现有应用程序，并且必须适应这些应用程序的更改。消息通道使应用程序不必知道彼此的位置。消息路由器甚至可以使应用程序不必就公共消息通道达成一致。然而，如果应用程序仍然依赖于彼此的数据格式，这种形式的解耦只能在应用程序之间实现有限的独立性。消息翻译器可以消除这种额外的依赖性。

Many of the design trade-offs in in­teg­ra­tion are driven by the need to de­couple com­pon­ents or ap­plic­a­tions. De­coup­ling is an es­sen­tial tool to enable the man­age­ment of change. In­teg­ra­tion typ­ic­ally con­nects ex­ist­ing ap­plic­a­tions and has to ac­com­mod­ate changes to these ap­plic­a­tions. Mes­sage Chan­nels de­couple ap­plic­a­tions from having to know each other's loc­a­tion. A Mes­sage Router can even de­couple ap­plic­a­tions from having to agree on a common Mes­sage Chan­nel. How­ever, this form of de­coup­ling achieves only lim­ited in­de­pend­ence between ap­plic­a­tions if they still depend on each other's data formats. A Mes­sage Trans­lator can remove this ad­di­tional level of de­pend­ency.

链接转换

Chain­ing Trans­form­a­tions

许多业务场景需要不止一层的转换。例如，假设表示为固定格式文件的 EDI 850 采购订单记录必须转换为通过 HTTP 发送到订单管理系统的 XML 文档，该系统使用不同的 Order 对象定义。所需的转换跨越所有四个级别：传输从文件传输更改为HTTP，数据格式从固定字段格式更改为XML，并且数据类型和数据格式都必须转换以符合Order由订单管理系统定义的对象。分层模型的优点在于，您可以处理一层而不必担心较低层，因此可以一次专注于一个抽象级别（请参见下图）。

Many busi­ness scen­arios re­quire trans­form­a­tions at more than one layer. For ex­ample, let's assume an EDI 850 Pur­chase Order record rep­res­en­ted as a fixed-format file has to be trans­lated to an XML doc­u­ment sent over HTTP to the order man­age­ment system, which uses a dif­fer­ent defin­i­tion of the Order object. The re­quired trans­form­a­tion spans all four levels: The trans­port changes from file trans­fer to HTTP, the data format changes from a fixed-field format to XML, and both data types and data formats have to be con­ver­ted to comply with the Order object defined by the order man­age­ment system. The beauty of a layered model is that you can treat one layer without wor­ry­ing about the lower layers and there­fore can focus on one level of ab­strac­tion at a time (see the fol­low­ing figure).

跨多个层的映射

Map­ping Across Mul­tiple Layers

使用管道和过滤器链接多个消息转换器单元会产生以下架构（请参见下一页的图）。为每一层创建一个消息转换器允许我们在其他场景中重用这些组件。例如，通道适配器和EDI 到 XML消息转换器可以以通用方式实现，以便它们可以重新用于任何传入的 EDI 文档。

Chain­ing mul­tiple Mes­sage Trans­lator units using Pipes and Fil­ters res­ults in the fol­low­ing ar­chi­tec­ture (see figure on the next page). Cre­at­ing one Mes­sage Trans­lator for each layer allows us to reuse these com­pon­ents in other scen­arios. For ex­ample, the Chan­nel Ad­apter and the EDI-to-XML Mes­sage Trans­lator can be im­ple­men­ted in a gen­eric fash­ion so that they can be reused for any in­com­ing EDI doc­u­ment.

链接多个 消息转换器

Chain­ing Mul­tiple Mes­sage Trans­lat­ors

链接多个消息转换器还允许您更改单个层使用的转换，而不影响任何其他层。您可以使用相同的结构转换机制，但不是将数据表示形式转换为固定格式，而是可以通过交换数据表示形式转换将其转换为逗号分隔的文件。

Chain­ing mul­tiple Mes­sage Trans­lators also allows you to change the trans­form­a­tions used at an in­di­vidual layer without af­fect­ing any of the other layers. You could use the same struc­tural trans­form­a­tion mech­an­isms, but in­stead of con­vert­ing the data rep­res­ent­a­tion into a fixed format, you could con­vert it into a comma-sep­ar­ated file by swap­ping out the data rep­res­ent­a­tion trans­form­a­tion.

消息翻译器模式有许多专业化和变体。信封包装器将消息数据包装在信封内，以便可以在消息传递系统中传输。内容丰富器增强消息内的信息，而内容过滤器则删除信息。索赔检查删除信息但将其存储以供以后检索。Normalizer可以将多种不同的消息格式转换为一致的格式。最后，规范数据模型展示了如何利用多个消息转换器s 实现数据格式解耦。在每个模式中，都可能发生复杂的结构转换（例如，将多对多关系映射为一对一关系）。

There are many spe­cial­iz­a­tions and vari­ations of the Mes­sage Trans­lator pat­tern. An En­vel­ope Wrap­per wraps the mes­sage data inside an en­vel­ope so that it can be trans­por­ted across a mes­saging system. A Con­tent En­richer aug­ments the in­form­a­tion inside a mes­sage, whereas the Con­tent Filter re­moves in­form­a­tion. The Claim Check re­moves in­form­a­tion but stores it for later re­trieval. The Nor­mal­izer can con­vert a number of dif­fer­ent mes­sage formats into a con­sist­ent format. Last, the Ca­non­ical Data Model shows how to lever­age mul­tiple Mes­sage Trans­lators to achieve data format de­coup­ling. Inside each of those pat­terns, com­plex struc­tural trans­form­a­tions can occur (e.g., map­ping a many-to-many re­la­tion­ship into a one-to-one re­la­tion­ship).

<数据>
    <顾客>
        <名字>乔</名字>
        <姓氏>母鹿</姓氏>
        <地址类型=“主要”>
            <参考id =“55355”/>
        </地址>
        <地址类型=“次要”>
            <参考id =“77889”/>
        </地址>
    </客户>
    <地址id="55355">
        <街道>123 主要</街道>
        <城市>旧金山</城市>
        <州>加利福尼亚州</州>
        <邮政编码>94123</邮政编码>
        <国家>美国</国家>
        <手机类型=“手机”>
            <区域>415</区域>
            <前缀>555</前缀>
            <号码>1234</号码>
        </电话>
        <电话类型=“家庭”>
            <区域>415</区域>
            <前缀>555</前缀>
            <号码>5678</号码>
        </电话>
    </地址>
    <地址id="77889">
        <公司>ThoughtWorks</公司>
        <街>汤森410号</街>
        <城市>旧金山</城市>
        <州>加利福尼亚州</州>
        <邮政编码>94107</邮政编码>
        <国家>美国</国家>
    </地址>
</数据>

<data>
    <cus­tomer>
        <first­name>Joe</first­name>
        <last­name>Doe</last­name>
        <ad­dress type="primary">
            <ref id="55355"/>
        </ad­dress>
        <ad­dress type="sec­ond­ary">
            <ref id="77889"/>
        </ad­dress>
    </cus­tomer>
    <ad­dress id="55355">
        <street>123 Main</street>
        <city>San Fran­cisco</city>
        <state>CA</state>
        <postalcode>94123</postalcode>
        <coun­try>USA</coun­try>
        <phone type="cell">
            <area>415</area>
            <prefix>555</prefix>
            <number>1234</number>
        </phone>
        <phone type="home">
            <area>415</area>
            <prefix>555</prefix>
            <number>5678</number>
        </phone>
    </ad­dress>
    <ad­dress id="77889">
        <com­pany>Thought­Works</com­pany>
        <street>410 Town­send</street>
        <city>San Fran­cisco</city>
        <state>CA</state>
        <postalcode>94107</postalcode>
        <coun­try>USA</coun­try>
    </ad­dress>
</data>

<昆德>
    <姓名>乔·多伊</姓名>
    <地址>
        <大街>123号大街</大街>
        <Ort>旧金山</Ort>
        <电话>415-555-1234</电话>
    </地址>
</昆德>

<Kunde>
    <Name>Joe Doe</Name>
    <Ad­resse>
        <Strasse>123 Main</Strasse>
        <Ort>San Fran­cisco</Ort>
        <Tele­fon>415-555-1234</Tele­fon>
    </Ad­resse>
</Kunde>

[查看全宽]
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999
/XSL/转换">
    <xsl:输出方法=“xml”缩进=“是”/>
    <xsl:key name="addrlookup" match="/data/address" use="@id"/>
    <xsl：模板匹配=“数据”>
        <xsl:apply-templates select="客户"/>
    </xsl：模板>
    <xsl:模板匹配=“客户”>
        <昆德>
            <名称>
                <xsl:value-of select="concat(名字, ' ',
姓氏）​​"/>
            </名称>
            <地址>
                <xsl:变量名称=“id”选择=“。
/地址[@type='primary']/ref/@id"/>
                <xsl:call-template name="getaddr">
                    <xsl:with-param name="addr" select="key
('addrlookup', $id)"/>
                </xsl：调用模板>
            </地址>
        </昆德>
    </xsl：模板>
    <xsl:模板名称=“getaddr”>
        <xsl:param name="addr"/>
        <大街>
            <xsl:value-of select="$addr/street"/>
        </大街>
        <奥尔特>
            <xsl:value-of select="$addr/city"/>
        </Ort>
        <电话>
            <xsl：选择>
                <xsl:when test="$addr/phone[@type='cell']">
                    <xsl:apply-templates select="$addr
/phone[@type='cell']" mode="getphone"/>
                </xsl：何时>

                <xsl：否则>
                    <xsl:apply-templates select="$addr
/phone[@type='home']" mode="getphone"/>
                </xsl：否则>
            </xsl：选择>
        </电话>
    </xsl：模板>
    <xsl:template match="phone" mode="getphone">
        <xsl:value-of select="concat(区域, '-', 前缀, '-',
数）"/>
    </xsl：模板>
    <xsl:模板匹配="*"/>
</xsl：样式表>

[View full width]
<xsl:stylesheet ver­sion="1.0" xmlns:xsl="http://www.w3.org/1999
/XSL/Trans­form">
    <xsl:output method="xml" indent="yes"/>
    <xsl:key name="ad­drlookup" match="/data/ad­dress" use="@id"/>
    <xsl:tem­plate match="data">
        <xsl:apply-tem­plates select="cus­tomer"/>
    </xsl:tem­plate>
    <xsl:tem­plate match="cus­tomer">
        <Kunde>
            <Name>
                <xsl:value-of select="concat(first­name, ' ',
 last­name)"/>
            </Name>
            <Ad­resse>
                <xsl:vari­able name="id" select=".
/ad­dress[@type='primary']/ref/@id"/>
                <xsl:call-tem­plate name="get­addr">
                    <xsl:with-param name="addr" select="key
('ad­drlookup', $id)"/>
                </xsl:call-tem­plate>
            </Ad­resse>
        </Kunde>
    </xsl:tem­plate>
    <xsl:tem­plate name="get­addr">
        <xsl:param name="addr"/>
        <Strasse>
            <xsl:value-of select="$addr/street"/>
        </Strasse>
        <Ort>
            <xsl:value-of select="$addr/city"/>
        </Ort>
        <Tele­fon>
            <xsl:choose>
                <xsl:when test="$addr/phone[@type='cell']">
                    <xsl:apply-tem­plates select="$addr
/phone[@type='cell']" mode="get­phone"/>
                </xsl:when>

                <xsl:oth­er­wise>
                    <xsl:apply-tem­plates select="$addr
/phone[@type='home']" mode="get­phone"/>
                </xsl:oth­er­wise>
            </xsl:choose>
        </Tele­fon>
    </xsl:tem­plate>
    <xsl:tem­plate match="phone" mode="get­phone">
        <xsl:value-of select="concat(area, '-', prefix, '-',
 number)"/>
    </xsl:tem­plate>
    <xsl:tem­plate match="*"/>
</xsl:stylesheet>

<xsl:模板匹配=“客户”>

<xsl:tem­plate match="cus­tomer">

消息端点

Message Endpoint

应用程序通过消息发送消息来进行通信。

Ap­plic­a­tions are com­mu­nic­at­ing by send­ing Mes­sages to each other via Mes­sage Chan­nels.

应用程序和消息系统是两套独立的软件。应用程序为某种类型的用户提供功能，而消息传递系统管理用于传输消息以进行通信的消息传递通道。即使消息传递系统被合并为应用程序的基本部分，它仍然是一个独立的、专门的功能提供者，很像数据库管理系统或 Web 服务器。由于应用程序和消息传递系统是分开的，因此它们必须有一种连接和协同工作的方式。

The ap­plic­a­tion and the mes­saging system are two sep­ar­ate sets of soft­ware. The ap­plic­a­tion provides func­tion­ally for some type of user, whereas the mes­saging system man­ages mes­saging chan­nels for trans­mit­ting mes­sages for com­mu­nic­a­tion. Even if the mes­saging system is in­cor­por­ated as a fun­da­mental part of the ap­plic­a­tion, it is still a sep­ar­ate, spe­cial­ized pro­vider of func­tion­al­ity, much like a data­base man­age­ment system or a Web server. Be­cause the ap­plic­a­tion and the mes­saging system are sep­ar­ate, they must have a way to con­nect and work to­gether.

应用程序与消息通道断开连接

Ap­plic­a­tions Dis­con­nec­ted from a Mes­sage Chan­nel

消息传递系统是一种服务器，能够接受请求并响应它们。就像数据库接受和检索数据一样，消息传递服务器接受和传递消息。消息传递系统是消息传递服务器。

A mes­saging system is a type of server, cap­able of taking re­quests and re­spond­ing to them. Like a data­base ac­cept­ing and re­triev­ing data, a mes­saging server ac­cepts and de­liv­ers mes­sages. A mes­saging system is a mes­saging server.

服务器需要客户端，而使用消息传递的应用程序是消息传递服务器的客户端。但应用程序不一定知道如何成为消息传递客户端，就像它们不一定知道如何成为数据库客户端一样。消息传递服务器与数据库服务器一样，具有客户端 API，应用程序可以使用该 API 与服务器进行交互。API 不是特定于应用程序的，而是特定于域的，其中域是消息传递的。应用程序必须包含一组将消息传递域与应用程序连接和统一的代码，以允许应用程序执行消息传递。

A server needs cli­ents, and an ap­plic­a­tion that uses mes­saging is a client of the mes­saging server. But ap­plic­a­tions do not ne­ces­sar­ily know how to be mes­saging cli­ents any more than they know how to be data­base cli­ents. The mes­saging server, like a data­base server, has a client API that the ap­plic­a­tion can use to in­ter­act with the server. The API is not ap­plic­a­tion-spe­cific but is domain-spe­cific, where the domain is mes­saging. The ap­plic­a­tion must con­tain a set of code that con­nects and unites the mes­saging domain with the ap­plic­a­tion to allow the ap­plic­a­tion to per­form mes­saging.

消息端点代码是应用程序和消息系统的客户端 API 自定义的。应用程序的其余部分对消息格式、消息传递通道或通过消息传递与其他应用程序进行通信的任何其他细节知之甚少。它只知道它有一个请求或数据要发送到另一个应用程序，或者期待来自另一个应用程序的请求或数据。消息传送端点代码接收该命令或数据，将其制作成消息，并将其发送到特定的消息传送通道。它是接收消息、提取内容并以有意义的方式将其提供给应用程序的端点。

Mes­sage En­d­point code is custom to both the ap­plic­a­tion and the mes­saging system's client API. The rest of the ap­plic­a­tion knows little about mes­sage formats, mes­saging chan­nels, or any of the other de­tails of com­mu­nic­at­ing with other ap­plic­a­tions via mes­saging. It just knows that it has a re­quest or piece of data to send to an­other ap­plic­a­tion, or is ex­pect­ing those from an­other ap­plic­a­tion. It is the mes­saging en­d­point code that takes that com­mand or data, makes it into a mes­sage, and sends it on a par­tic­u­lar mes­saging chan­nel. It is the en­d­point that re­ceives a mes­sage, ex­tracts the con­tents, and gives them to the ap­plic­a­tion in a mean­ing­ful way.

消息端点将消息传递系统与应用程序的其余部分封装在一起，并为特定应用程序和任务定制通用消息传递 API。如果使用特定消息 API 的应用程序要切换到另一个，开发人员将必须重写消息端点代码，但应用程序的其余部分应保持不变。如果新版本的消息传递系统更改了消息传递 API，则这只会影响消息端点代码。如果应用程序决定通过消息传递以外的某种方式与其他人进行通信，那么开发人员理想情况下应该能够重写消息端点代码，但保持应用程序的其余部分不变。

The Mes­sage En­d­point en­cap­su­lates the mes­saging system from the rest of the ap­plic­a­tion and cus­tom­izes a gen­eral mes­saging API for a spe­cific ap­plic­a­tion and task. If an ap­plic­a­tion using a par­tic­u­lar mes­saging API were to switch to an­other, de­ve­lopers would have to re­write the mes­sage en­d­point code, but the rest of the ap­plic­a­tion should remain the same. If a new ver­sion of a mes­saging system changes the mes­saging API, this should only affect the mes­sage en­d­point code. If the ap­plic­a­tion de­cides to com­mu­nic­ate with others via some means other than mes­saging, de­ve­lopers should ideally be able to re­write the mes­sage en­d­point code but leave the rest of the ap­plic­a­tion un­changed.

消息端点可用于发送或接收消息，但一个实例不能同时执行这两种操作。端点是特定于通道的，因此单个应用程序将使用多个端点与多个通道进行交互。应用程序可以使用多个端点实例来连接到单个通道，通常是为了支持多个并发线程。

A Mes­sage En­d­point can be used to send mes­sages or re­ceive them, but one in­stance does not do both. An en­d­point is chan­nel-spe­cific, so a single ap­plic­a­tion would use mul­tiple en­d­points to in­ter­face with mul­tiple chan­nels. An ap­plic­a­tion may use mul­tiple en­d­point in­stances to in­ter­face to a single chan­nel, usu­ally to sup­port mul­tiple con­cur­rent threads.

消息端点是一种专门的通道适配器，是为其应用程序定制开发并集成到其应用程序中的。

A Mes­sage En­d­point is a spe­cial­ized Chan­nel Ad­apter one that has been custom de­ve­loped for and in­teg­rated into its ap­plic­a­tion.

消息端点应设计为消息传递网关，以封装消息传递代码并向应用程序的其余部分隐藏消息系统。它可以使用消息传递映射器在域对象和消息之间传输数据。它可以被构造为服务激活器，以提供对同步服务或函数调用的异步消息访问。端点可以作为事务客户端显式地控制与消息传递系统的事务。

A Mes­sage En­d­point should be de­signed as a Mes­saging Gate­way to en­cap­su­late the mes­saging code and hide the mes­sage system from the rest of the ap­plic­a­tion. It can employ a Mes­saging Mapper to trans­fer data between domain ob­jects and mes­sages. It can be struc­tured as a Ser­vice Ac­tiv­ator to provide asyn­chron­ous mes­sage access to a syn­chron­ous ser­vice or func­tion call. An en­d­point can ex­pli­citly con­trol trans­ac­tions with the mes­saging system as a Trans­ac­tional Client.

发送消息非常容易，因此许多端点模式涉及接收消息的不同方法。消息接收者可以是轮询消费者或事件驱动消费者。多个消费者可以作为竞争消费者或通过消息调度程序从同一通道接收消息。接收者可以使用Selective Consumer 来决定使用或忽略哪些消息。它可以使用持久订阅者来确保订阅者不会错过端点断开连接时发布的消息。消费者可以是幂等接收者正确检测并处理重复消息。

Send­ing mes­sages is pretty easy, so many en­d­point pat­terns con­cern dif­fer­ent ap­proaches for re­ceiv­ing mes­sages. A mes­sage re­ceiver can be a Polling Con­sumer or an Event-Driven Con­sumer. Mul­tiple con­sumers can re­ceive mes­sages from the same chan­nel either as Com­pet­ing Con­sumers or via a Mes­sage Dis­patcher. A re­ceiver can decide which mes­sages to con­sume or ignore using a Se­lect­ive Con­sumer. It can use a Dur­able Sub­scriber to make sure a sub­scriber does not miss mes­sages pub­lished while the en­d­point is dis­con­nec­ted. And the con­sumer can be an Idem­potent Re­ceiver that cor­rectly de­tects and handles du­plic­ate mes­sages.

第 4 章消息传递渠道

Chapter 4. Messaging Channels

介绍

In­tro­duc­tion

点对点通道

Point-to-Point Chan­nel

发布订阅通道

Pub­lish-Sub­scribe Chan­nel

数据类型通道

Data­type Chan­nel

消息通道无效

In­valid Mes­sage Chan­nel

死信频道

Dead Letter Chan­nel

保证交付

Guar­an­teed De­liv­ery

通道适配器

Chan­nel Ad­apter

消息桥

Mes­saging Bridge

消息总线

Mes­sage Bus

介绍

Introduction

在第 3 章“消息系统”中，我们讨论了消息通道。当两个应用程序想要交换数据时，它们通过连接两个应用程序的通道发送数据来实现。发送数据的应用程序可能不知道哪个应用程序将接收数据。然而，通过选择发送数据的特定通道，发送方知道接收方将通过在该通道上查找来寻找此类数据。通过这种方式，生成共享数据的应用程序可以与那些希望使用该数据的应用程序进行通信。

In Chapter 3, "Mes­saging Sys­tems," we dis­cussed Mes­sage Chan­nels. When two ap­plic­a­tions want to ex­change data, they do so by send­ing the data through a chan­nel that con­nects the two. The ap­plic­a­tion send­ing the data may not know which ap­plic­a­tion will re­ceive the data. How­ever, by se­lect­ing a par­tic­u­lar chan­nel on which to send the data, the sender knows that the re­ceiver will be one that is look­ing for that sort of data by look­ing for it on that chan­nel. In this way, the ap­plic­a­tions that pro­duce shared data have a way to com­mu­nic­ate with those that wish to con­sume it.

消息频道主题

Mes­sage Chan­nel Themes

决定使用消息通道是很简单的部分；如果应用程序有数据要传输或希望接收数据，则它必须使用通道。挑战在于了解您的应用程序需要哪些渠道以及它们的用途。

De­cid­ing to use a Mes­sage Chan­nel is the simple part; if an ap­plic­a­tion has data to trans­mit or data it wishes to re­ceive, it will have to use a chan­nel. The chal­lenge is know­ing what chan­nels your ap­plic­a­tions will need and what to use them for.

固定通道集 本章讨论的 一个主题是消息通道集应用程序可用的内容往往是静态的。在设计应用程序时，开发人员必须知道在哪里放置什么类型的数据以便与其他应用程序共享该数据，以及在哪里查找来自其他应用程序的特定类型的数据。这些通信路径无法在运行时动态创建和发现；它们需要在设计时达成一致，以便应用程序知道其数据来自何处以及数据将去往何处。（虽然大多数通道确实必须静态定义，但也有例外，在这种情况下动态通道是实用且有用的。一个例外是请求-应答中的应答通道。请求者可以创建或获取回复者一无所知的新通道，并将其指定为请求消息的返回地址。然后回复者就可以使用它。另一个例外是支持分层通道的消息传递系统实现。接收者可以订阅层次结构中的父通道，然后发送者可以发布到接收者一无所知的新子通道。订阅者仍会收到该消息。尽管存在这些相对不寻常的情况，但通道通常是在部署之前定义的，并且应用程序是围绕一组已知的通道设计的。）

确定通道集 一个 相关的问题是，谁决定什么消息通道消息系统或应用程序可用吗？换句话说，消息传递系统是否定义了某些通道并要求应用程序使用这些通道？或者应用程序是否确定它们需要什么通道并要求消息系统提供它们？没有简单的答案；设计所需的通道集是迭代的。首先，应用程序确定消息系统需要提供哪些通道。后续应用程序将尝试围绕可用通道设计通信，但当这不切实际时，它们将要求添加额外的通道。当一组应用程序已经使用一组特定的通道并且新的应用程序想要加入时，它们也将使用现有的一组通道。

单向通道 另一个常见的混淆来源是消息通道是否是单向或双向的。从技术上讲，两者都不是；通道更像是一个存储桶，一些应用程序向其中添加数据，其他应用程序从中获取数据（尽管存储桶以某种协调的方式分布在多台计算机上）。但由于数据位于从一个应用程序传输到另一个应用程序的消息中，因此这就给出了通道方向，使其成为单向的。如果通道是双向的，则意味着应用程序将向同一通道发送消息并从同一通道接收消息，这虽然在技术上可能没有什么意义，因为应用程序往往会继续消耗自己的消息：它应该发送到的消息其他应用程序。因此，出于所有实际目的，通道是单向的。因此，要使两个应用程序进行双向对话，它们需要两个通道，每个方向一个（请参阅请求-答复将在下一章中介绍）。

Fixed set of chan­nels One topic dis­cussed in this chapter is that the set of Mes­sage Chan­nels avail­able to an ap­plic­a­tion tends to be static. When design­ing an ap­plic­a­tion, a de­ve­loper must know where to put what types of data in order to share that data with other ap­plic­a­tions and like­wise where to look for par­tic­u­lar types of data coming from other ap­plic­a­tions. These paths of com­mu­nic­a­tion cannot be dy­nam­ic­ally cre­ated and dis­covered at runtime; they need to be agreed upon at design time so that the ap­plic­a­tion knows where its data is coming from and where the data is going to. (While it is true that most chan­nels must be stat­ic­ally defined, there are ex­cep­tions, cases where dy­namic chan­nels are prac­tical and useful. One ex­cep­tion is the reply chan­nel in Re­quest-Reply. The re­questor can create or obtain a new chan­nel that the replier knows noth­ing about and spe­cify it as the Return Ad­dress of a re­quest mes­sage. The replier can then use it. An­other ex­cep­tion is mes­saging system im­ple­ment­a­tions that sup­port hier­arch­ical chan­nels. A re­ceiver can sub­scribe to a parent in the hier­archy, and then a sender can pub­lish to a new child chan­nel that the re­ceiver knows noth­ing about. The sub­scriber will still re­ceive the mes­sage. These re­l­at­ively un­usual cases not­with­stand­ing, chan­nels are usu­ally defined before de­ploy­ment, and ap­plic­a­tions are de­signed around a known set of chan­nels.)

De­term­in­ing the set of chan­nels A re­lated issue is, Who de­cides what Mes­sage Chan­nels are avail­ab­lethe mes­saging system or the ap­plic­a­tions? In other words, does the mes­saging system define cer­tain chan­nels and re­quire the ap­plic­a­tions to make do with those? Or do the ap­plic­a­tions de­term­ine what chan­nels they need and re­quire the mes­saging system to provide them? There is no simple answer; design­ing the needed set of chan­nels is it­er­at­ive. First, the ap­plic­a­tions de­term­ine which chan­nels the mes­saging system needs to provide. Sub­se­quent ap­plic­a­tions will try to design their com­mu­nic­a­tion around the chan­nels that are avail­able, but when this is not prac­tical, they will re­quire that ad­di­tional chan­nels be added. When a set of ap­plic­a­tions already uses a cer­tain set of chan­nels, and new ap­plic­a­tions want to join in, they too will use the ex­ist­ing set of chan­nels. When ex­ist­ing ap­plic­a­tions add new func­tion­al­ity, they may re­quire new chan­nels.

Uni­direc­tional chan­nels An­other common source of con­fu­sion is whether a Mes­sage Chan­nel is uni­direc­tional or bi­d­irec­tional. Tech­nic­ally, it's neither; a chan­nel is more like a bucket that some ap­plic­a­tions add data to and other ap­plic­a­tions take data from (albeit a bucket that is dis­trib­uted across mul­tiple com­puters in some co­ordin­ated fash­ion). But be­cause the data is in mes­sages that travel from one ap­plic­a­tion to an­other, that gives the chan­nel dir­ec­tion, making it uni­direc­tional. If a chan­nel were bi­d­irec­tional, that would mean that an ap­plic­a­tion would both send mes­sages to and re­ceive mes­sages from the same chan­nel, which­while tech­nic­ally pos­sible­makes little sense be­cause the ap­plic­a­tion would tend to keep con­sum­ing its own mes­sages: the mes­sages it's sup­posed to be send­ing to other ap­plic­a­tions. So, for all prac­tical pur­poses, chan­nels are uni­direc­tional. As a con­se­quence, for two ap­plic­a­tions to have a two-way con­ver­sa­tion, they need two chan­nels, one in each dir­ec­tion (see Re­quest-Reply in the next chapter).

消息渠道决策

Mes­sage Chan­nel De­cisions

现在我们了解了消息通道是什么，让我们考虑使用它们所涉及的决策。

Now that we un­der­stand what Mes­sage Chan­nels are, let's con­sider the de­cisions in­volved in using them.

一对一或一对多 当您的应用程序共享一段数据时，您希望仅与一个其他应用程序还是与任何其他感兴趣的应用程序共享它？要将数据发送到单个应用程序，请使用点对点通道。这并不能保证在该通道上发送的每条数据都一定会发送到同一个接收器，因为该通道可能有多个接收器。然而，它确实确保任何一份数据仅被一个应用程序接收。如果您希望所有接收器应用程序都能够接收数据，请使用Publish-Subscribe Channel 。当您以这种方式发送一段数据时，通道会有效地为每个接收者复制数据。

什么类型的数据 任何计算机内存中的任何数据都必须符合某种类型：具有商定含义的已知格式或预期结构。否则，所有数据都只是一堆字节，并且无法理解它。消息系统的工作方式大致相同；消息内容必须符合某种类型，以便接收者理解数据的结构。数据类型通道的理念是通道上的所有数据必须属于同一类型。这是消息传递系统需要大量通道的主要原因。如果数据可以是任何类型，则消息传递系统在任意两个应用程序之间只需要一个通道（在每个方向）。

无效消息和 死消息消息系统可以确保消息正确传递，但不能保证接收者知道如何处理它。接收者对数据的类型和含义有期望。当它收到不符合这些期望的消息时，它无能为力。不过，它可以做的就是将奇怪的消息放在专门指定的无效消息通道上，希望监视该通道的某些实用程序能够拾取该消息并找出如何处理它。许多消息传递系统都有类似的内置功能，即死信通道，对于已成功发送但最终无法成功投递的消息。同样，系统管理实用程序应该监视死信通道并决定如何处理无法传递的消息。

防崩溃 如果消息系统崩溃或关闭进行维护，其消息会发生什么情况？当它恢复并运行时，它的消息仍然在它的通道中吗？默认情况下，否；通道将其消息存储在内存中。然而，保证交付使通道持久化，以便它们的消息存储在磁盘上。这会损害性能，但会使消息传递更加可靠，即使消息传递系统并不可靠。

非消息传递客户端 如果应用程序无法连接到消息传递系统但仍想参与消息传递 怎么办？通常情况下，这会很不幸，但如果消息传递系统可以通过其用户界面、业务服务 API、数据库或网络连接（例如 TCP/IP 或 HTTP）以某种方式连接到应用程序，那么通道适配器就可以使用消息系统。这允许您将一个通道（或一组通道）连接到应用程序，而无需修改应用程序，并且可能不需要消息客户端与应用程序在同一台计算机上运行。有时，“非消息传递客户端”确实是消息传递客户端，但只是针对不同的消息传递系统。在这种情况下，作为两个消息传递系统上的客户端的应用程序可以在两者之间构建消息传递桥，从而有效地将它们连接到一个复合消息传递系统中。

通信主干 随着 越来越多的企业应用程序连接到消息传递系统并通过消息传递提供其功能，消息传递系统成为企业中共享功能的一站式采购的集中点。新应用程序只需要知道使用哪些通道来请求功能以及监听哪些其他通道来获取结果。消息传递系统本身本质上成为消息总线，它是提供对企业所有各种且不断变化的应用程序和功能的访问的主干网。通过从一开始就专门设计，您可以更快、更轻松地实现这种集成必杀技。

One-to-one or one-to-many When your ap­plic­a­tion shares a piece of data, do you want to share it with just one other ap­plic­a­tion or with any other ap­plic­a­tion that is in­ter­ested? To send the data to a single ap­plic­a­tion, use a Point-to-Point Chan­nel. This does not guar­an­tee that every piece of data sent on that chan­nel will ne­ces­sar­ily go to the same re­ceiver, be­cause the chan­nel might have mul­tiple re­ceiv­ers. It does, how­ever, ensure that any one piece of data will be re­ceived by only one of the ap­plic­a­tions. If you want all of the re­ceiver ap­plic­a­tions to be able to re­ceive the data, use a Pub­lish-Sub­scribe Chan­nel. When you send a piece of data this way, the chan­nel ef­fect­ively copies the data for each of the re­ceiv­ers.

What type of data Any data in any com­puter memory has to con­form to some sort of type: a known format or ex­pec­ted struc­ture with an agreed-upon mean­ing. Oth­er­wise, all data would just be a bunch of bytes, and there would be no way to make any sense out of it. Mes­saging sys­tems work much the same way; the mes­sage con­tents must con­form to some type so that the re­ceiver un­der­stands the data's struc­ture. Data­type Chan­nel is the idea that all of the data on a chan­nel must be of the same type. This is the main reason that mes­saging sys­tems need lots of chan­nels. If the data could be of any type, the mes­saging system would only need one chan­nel (in each dir­ec­tion) between any two ap­plic­a­tions.

In­valid and dead mes­sages The mes­sage system can ensure that a mes­sage is de­livered prop­erly, but it cannot guar­an­tee that the re­ceiver will know what to do with it. The re­ceiver has ex­pect­a­tions about the data's type and mean­ing. When it re­ceives a mes­sage that doesn't meet these ex­pect­a­tions, there's not much it can do. What it can do, though, is put the strange mes­sage on a spe­cially des­ig­nated In­valid Mes­sage Chan­nel in hopes that some util­ity mon­it­or­ing the chan­nel will pick up the mes­sage and figure out what to do with it. Many mes­saging sys­tems have a sim­ilar built-in fea­ture, a Dead Letter Chan­nel, for mes­sages that are suc­cess­fully sent but ul­ti­mately cannot be suc­cess­fully de­livered. Again, a system man­age­ment util­ity should mon­itor the Dead Letter Chan­nel and decide what to do with the mes­sages that could not be de­livered.

Crash proof If the mes­saging system crashes or is shut down for main­ten­ance, what hap­pens to its mes­sages? When it is back up and run­ning, will its mes­sages still be in its chan­nels? By de­fault, no; chan­nels store their mes­sages in memory. How­ever, Guar­an­teed De­liv­ery makes chan­nels per­sist­ent so that their mes­sages are stored on disk. This hurts per­form­ance but makes mes­saging more re­li­able, even when the mes­saging system isn't.

Non-mes­saging cli­ents What if an ap­plic­a­tion cannot con­nect to a mes­saging system but still wants to par­ti­cip­ate in mes­saging? Nor­mally it would be out of luck, but if the mes­saging system can con­nect to the ap­plic­a­tion some­how­through its user in­ter­face, its busi­ness ser­vices API, its data­base, or a net­work con­nec­tion such as TCP/IP or HT­TPthen a Chan­nel Ad­apter on the mes­saging system can be used. This allows you to con­nect a chan­nel (or set of chan­nels) to the ap­plic­a­tion without having to modify the ap­plic­a­tion and per­haps without re­quir­ing a mes­saging client run­ning on the same ma­chine as the ap­plic­a­tion. Some­times the "non-mes­saging client" really is a mes­saging client, but just for a dif­fer­ent mes­saging system. In that case, an ap­plic­a­tion that is a client on both mes­saging sys­tems can build a Mes­saging Bridge between the two, ef­fect­ively con­nect­ing them into one com­pos­ite mes­saging system.

Com­mu­nic­a­tions back­bone As more and more of an en­ter­prise's ap­plic­a­tions con­nect to the mes­saging system and make their func­tion­al­ity avail­able through mes­saging, the mes­saging system be­comes a cent­ral­ized point of one-stop shop­ping for shared func­tion­al­ity in the en­ter­prise. A new ap­plic­a­tion simply needs to know which chan­nels to use to re­quest func­tion­al­ity and which others to listen on for the res­ults. The mes­saging system itself es­sen­tially be­comes a Mes­sage Bus, a back­bone provid­ing access to all of the en­ter­prise's vari­ous and ever-chan­ging ap­plic­a­tions and func­tion­al­ity. You can achieve this in­teg­ra­tion nir­vana more quickly and easily by spe­cific­ally design­ing for it from the be­gin­ning.

正如您所看到的，为消息传递设置应用程序不仅仅涉及将它们连接到消息传递系统以便它们可以发送消息。消息必须有消息通道来传输。仅仅在某些渠道上进行打压也无法完成工作。它们的设计必须有一个目的，基于共享的数据类型、提供数据的应用程序类型以及接收数据的应用程序类型。本章解释了设计这些渠道时的决策。

As you can see, get­ting ap­plic­a­tions set up for Mes­saging in­volves more than just con­nect­ing them to the mes­saging system so that they can send mes­sages. The mes­sages must have Mes­sage Chan­nels to trans­mit on. Simply slap­ping in some chan­nels doesn't get the job done either. They have to be de­signed with a pur­pose, based on the data­type being shared, the sort of ap­plic­a­tion making the data avail­able, and the sort of ap­plic­a­tion re­ceiv­ing the data. This chapter ex­plains the de­cisions that go into design­ing these chan­nels.

为了帮助说明这些模式，每个模式都提供了一个来自虚构的、简化的股票交易领域的示例。虽然这些示例都不应该用作实现真实交易系统的基础，但它们确实可以作为如何使用模式的简短而具体的示例。

To help il­lus­trate the pat­terns, each one has an ex­ample from a fic­ti­tious, sim­pli­fied stock trad­ing domain. While none of these ex­amples should be used as the basis for im­ple­ment­ing a real trad­ing system, they do serve as brief and spe­cific ex­amples of how the pat­terns can be used.

点对点通道

Point-to-Point Channel

应用程序正在使用消息传递进行远程过程调用 (RPC) 或传输文档。

An ap­plic­a­tion is using Mes­saging to make remote pro­ced­ure calls (RPCs) or trans­fer doc­u­ments.

RPC 的优点之一是它是在单个远程进程上调用的，因此接收方要么执行该过程，要么不执行（并且会发生异常）。由于接收方仅被调用一次，因此它仅执行该过程一次。但对于消息传递，一旦呼叫被打包为消息并放置在消息通道上，许多接收者可能会在通道上看到它并决定执行该过程。

One ad­vant­age of an RPC is that it's in­voked on a single remote pro­cess, so either that re­ceiver per­forms the pro­ced­ure or it does not (and an ex­cep­tion occurs). And since the re­ceiver was called only once, it per­forms the pro­ced­ure only once. But with mes­saging, once a call is pack­aged as a Mes­sage and placed on a Mes­sage Chan­nel, po­ten­tially many re­ceiv­ers could see it on the chan­nel and decide to per­form the pro­ced­ure.

消息传递系统可以防止多个接收器监视单个通道，但这会不必要地限制希望向多个接收器传输数据的呼叫者。通道上的所有接收器可以进行协调，以确保只有其中一个接收器实际执行该过程，但这会很复杂，会产生大量通信开销，并且通常会增加其他独立接收器之间的耦合。单个通道上的多个接收器可能是理想的，以便可以同时使用多个消息，但任何一个接收器都应该使用任何单个消息。

The mes­saging system could pre­vent more than one re­ceiver from mon­it­or­ing a single chan­nel, but this would un­ne­ces­sar­ily limit callers that wish to trans­mit data to mul­tiple re­ceiv­ers. All of the re­ceiv­ers on a chan­nel could co­ordin­ate to ensure that only one of them ac­tu­ally per­forms the pro­ced­ure, but that would be com­plex, create a lot of com­mu­nic­a­tions over­head, and gen­er­ally in­crease the coup­ling between oth­er­wise in­de­pend­ent re­ceiv­ers. Mul­tiple re­ceiv­ers on a single chan­nel may be de­sir­able so that mul­tiple mes­sages can be con­sumed con­cur­rently, but any one re­ceiver should con­sume any single mes­sage.

点对点通道确保只有一个接收者消费任何给定的消息。通道可以有多个接收者，这些接收者可以同时消费多条消息，但只有其中一个可以成功消费某一特定消息。如果多个接收者尝试消费一条消息，通道会确保只有其中一个成功，因此接收者不必相互协调。

A Point-to-Point Chan­nel en­sures that only one re­ceiver con­sumes any given mes­sage. The chan­nel can have mul­tiple re­ceiv­ers that can con­sume mul­tiple mes­sages con­cur­rently, but only one of them can suc­cess­fully con­sume a par­tic­u­lar mes­sage. If mul­tiple re­ceiv­ers try to con­sume a single mes­sage, the chan­nel en­sures that only one of them suc­ceeds, so the re­ceiv­ers do not have to co­ordin­ate with each other.

当点对点通道只有一个消费者时，一条消息仅被消费一次这一事实并不奇怪。当通道有多个消费者时，它们就成为竞争消费者，并且通道确保只有一个消费者接收每条消息。这种设计使得消息的消费和处理具有高度的可扩展性，因为该工作可以在多台计算机上的多个应用程序中运行的多个消费者之间实现负载平衡。

When a Point-to-Point Chan­nel has only one con­sumer, the fact that a mes­sage gets con­sumed only once is not sur­pris­ing. When the chan­nel has mul­tiple con­sumers, then they become Com­pet­ing Con­sumers, and the chan­nel en­sures that only one of the con­sumers re­ceives each mes­sage. This design makes con­sum­ing and pro­cess­ing mes­sages highly scal­able be­cause that work can be load-bal­anced across mul­tiple con­sumers run­ning in mul­tiple ap­plic­a­tions on mul­tiple com­puters.

您使用点对点通道仅向其中一个可用接收者发送消息，而要将消息发送至所有可用接收者，请使用发布-订阅通道。要使用消息传递实现 RPC，请使用带有一对点对点 Channel 的Request-Reply。调用是命令消息，回复是文档消息。

Whereas you use a Point-to-Point Chan­nel to send a mes­sage to only one of the avail­able re­ceiv­ers, to send a mes­sage to all avail­able re­ceiv­ers, use a Pub­lish-Sub­scribe Chan­nel. To im­ple­ment RPCs using mes­saging, use Re­quest-Reply with a pair of Point-to-Point Chan­nels. The call is a Com­mand Mes­sage, and the reply is a Doc­u­ment Mes­sage.

[查看全宽]
Queuequeue = //通过JNDI获取队列
QueueConnectionFactoryfactory = // 获取连接工厂
通过 JNDI
QueueConnection 连接=factory.createQueueConnection();
QueueSession 会话 = connection.createQueueSession(true,
会话.AUTO_ACKNOWLEDGE);
QueueSender 发送者 = session.createSender(queue);

Message message = session.createTextMessage("消息内容
信息。”）;

发送者.发送(消息);

[View full width]
Queue queue = // obtain the queue via JNDI
QueueCon­nec­tion­Fact­ory fact­ory = // obtain the con­nec­tion fact­ory
 via JNDI
QueueCon­nec­tion con­nec­tion = fact­ory.cre­ateQueueCon­nec­tion();
QueueSes­sion ses­sion = con­nec­tion.cre­ateQueueSes­sion(true,
 Ses­sion.AUTO_AC­KNOW­LEDGE);
QueueSender sender = ses­sion.cre­ateSender(queue);

Mes­sage mes­sage = ses­sion.cre­at­e­Text­Mes­sage("The con­tents of the
 mes­sage.");

sender.send(mes­sage);

[查看全宽]
Queuequeue = //通过JNDI获取队列
QueueConnectionFactoryfactory = // 获取连接工厂
通过 JNDI
QueueConnection 连接=factory.createQueueConnection();
QueueSession 会话 = connection.createQueueSession(true,
会话.AUTO_ACKNOWLEDGE);
QueueReceiver 接收者 = session.createReceiver(queue);

TextMessage 消息 = (TextMessage)receiver.receive();
字符串内容 = message.getText();

[View full width]
Queue queue = // obtain the queue via JNDI
QueueCon­nec­tion­Fact­ory fact­ory = // obtain the con­nec­tion fact­ory
 via JNDI
QueueCon­nec­tion con­nec­tion = fact­ory.cre­ateQueueCon­nec­tion();
QueueSes­sion ses­sion = con­nec­tion.cre­ateQueueSes­sion(true,
 Ses­sion.AUTO_AC­KNOW­LEDGE);
QueueRe­ceiver re­ceiver = ses­sion.creat­eR­eceiver(queue);

Text­Mes­sage mes­sage = (Text­Mes­sage) re­ceiver.re­ceive();
String con­tents = mes­sage.get­Text();

MessageQueue 队列 = new MessageQueue("MyQ​​ueue");
queue.Send("消息的内容。");

Mes­sageQueue queue = new Mes­sageQueue("MyQueue");
queue.Send("The con­tents of the mes­sage.");

MessageQueue 队列 = new MessageQueue("MyQ​​ueue");
消息消息=queue.Receive();
字符串内容 = (String) message.Body();

Mes­sageQueue queue = new Mes­sageQueue("MyQueue");
Mes­sage mes­sage = queue.Re­ceive();
String con­tents = (String) mes­sage.Body();

发布订阅通道

Publish-Subscribe Channel

应用程序正在使用消息传递来宣布事件。

An ap­plic­a­tion is using Mes­saging to an­nounce events.

幸运的是，有一些完善的实施广播的模式。观察者模式[ GoF]描述了将观察者与其主体（即事件的发起者）解耦的需要，以便主体可以轻松地向所有感兴趣的观察者提供事件通知，无论有多少观察者（甚至没有）。发布者-订阅者模式[ POSA ]通过添加用于通信事件通知的事件通道的概念来扩展观察者。

Luck­ily, there are well-es­tab­lished pat­terns for im­ple­ment­ing broad­cast­ing. The Ob­server pat­tern [GoF] de­scribes the need to de­couple ob­serv­ers from their sub­ject (that is, the ori­gin­ator of the event) so that the sub­ject can easily provide event no­ti­fic­a­tion to all in­ter­ested ob­serv­ers no matter how many ob­serv­ers there are (even none). The Pub­lisher-Sub­scriber pat­tern [POSA] ex­pands upon Ob­server by adding the notion of an event chan­nel for com­mu­nic­at­ing event no­ti­fic­a­tions.

这就是理论，但它如何与消息传递一起工作呢？事件可以打包为消息，以便消息传递能够可靠地将事件传达给观察者（订阅者）。那么，事件通道就是Message Channel 。但是消息传递通道如何将事件正确地传达给所有订阅者呢？

That's the theory, but how does it work with mes­saging? The event can be pack­aged as a Mes­sage so that mes­saging will re­li­ably com­mu­nic­ate the event to the ob­serv­ers (sub­scribers). Then, the event chan­nel is a Mes­sage Chan­nel. But how will a mes­saging chan­nel prop­erly com­mu­nic­ate the event to all of the sub­scribers?

每个订阅者需要被通知一次特定事件，但不应该被重复通知同一事件。在通知所有订阅者之前，该事件不能被视为已消耗，但一旦通知了，该事件就可以被视为已消耗，并且应该从通道中消失。然而，让订阅者协调以确定何时使用消息违反了观察者模式的解耦。并发消费者不应该竞争，但应该能够共享事件消息。

Each sub­scriber needs to be no­ti­fied of a par­tic­u­lar event once but should not be no­ti­fied re­peatedly of the same event. The event cannot be con­sidered con­sumed until all of the sub­scribers have been no­ti­fied, but once they have, the event can be con­sidered con­sumed and should dis­ap­pear from the chan­nel. Yet, having the sub­scribers co­ordin­ate to de­term­ine when a mes­sage is con­sumed vi­ol­ates the de­coup­ling of the Ob­server pat­tern. Con­cur­rent con­sumers should not com­pete but should be able to share the event mes­sage.

发布-订阅通道的工作原理如下：它有一个输入通道，可分为多个输出通道，每个通道对应一个订阅者。当事件发布到通道中时，发布-订阅通道会将消息的副本传递到每个输出通道。通道的每个输出端只有一个订阅者，一条消息只能消费一次。通过这种方式，每个订阅者只收到一次消息，并且消耗的副本从他们的频道中消失。

A Pub­lish-Sub­scribe Chan­nel works like this: It has one input chan­nel that splits into mul­tiple output chan­nels, one for each sub­scriber. When an event is pub­lished into the chan­nel, the Pub­lish-Sub­scribe Chan­nel de­liv­ers a copy of the mes­sage to each of the output chan­nels. Each output end of the chan­nel has only one sub­scriber, which is al­lowed to con­sume a mes­sage only once. In this way, each sub­scriber gets the mes­sage only once, and con­sumed copies dis­ap­pear from their chan­nels.

发布-订阅通道可以是一个有用的调试工具。即使消息注定只能发送给单个接收者，但使用发布-订阅通道可以让您在不干扰现有消息流的情况下窃听消息通道。在调试消息传递应用程序时，监视通道上的所有流量非常有帮助。它还可以使您免于将大量打印语句插入到参与消息传递解决方案的每个应用程序中。创建一个程序来侦听所有活动通道上的消息并将其记录到文件中，可以提供与消息存储相同的许多好处。

A Pub­lish-Sub­scribe Chan­nel can be a useful de­bug­ging tool. Even though a mes­sage is destined to only a single re­ceiver, using a Pub­lish-Sub­scribe Chan­nel allows you to eaves­drop on a mes­sage chan­nel without dis­turb­ing the ex­ist­ing mes­sage flow. Mon­it­or­ing all traffic on a chan­nel can be tre­mend­ously help­ful when de­bug­ging mes­saging ap­plic­a­tions. It can also save you from in­sert­ing a ton of print state­ments into each ap­plic­a­tion that par­ti­cip­ates in the mes­saging solu­tion. Cre­at­ing a pro­gram that listens for mes­sages on all active chan­nels and logs them to a file can provide many of the same be­ne­fits that a Mes­sage Store brings.

然而，窃听发布-订阅通道的能力也可能成为一个缺点。如果您的消息传递解决方案在工资系统和会计系统之间传输工资数据，您可能不希望允许任何人编写简单的程序来侦听消息流量。点对点通道在一定程度上缓解了这个问题：因为窃听者会消耗通道外的消息，并且消息会突然丢失，所以可以很快检测到这种情况。然而，许多消息队列实现提供了查看功能，使消费者可以查看队列内的消息而不消耗任何消息。因此，订阅消息频道是应该受到安全策略限制的操作。许多（但不是全部）商业消息传递实现都实施了此类限制。此外，创建一个监控工具来记录消息通道的活动订阅者可能是一个有用的系统管理工具。

How­ever, the abil­ity to eaves­drop on a Pub­lish-Sub­scribe Chan­nel can also turn into a dis­ad­vant­age. If your mes­saging solu­tion trans­mits payroll data between the payroll system and the ac­count­ing system, you may not want to allow anyone to write a simple pro­gram to listen to the mes­sage traffic. Point-to-Point Chan­nels al­le­vi­ate the prob­lem some­what: Be­cause the eaves­drop­per would con­sume mes­sages off the chan­nel and mes­sages would sud­denly be miss­ing, the situ­ation could be de­tec­ted very quickly. How­ever, many mes­sage queue im­ple­ment­a­tions provide peek func­tions that let con­sumers look at mes­sages inside a queue without con­sum­ing any of the mes­sages. As a result, sub­scrib­ing to a Mes­sage Chan­nel is an op­er­a­tion that should be re­stric­ted by se­cur­ity policies. Many (but not all) com­mer­cial mes­saging im­ple­ment­a­tions im­ple­ment such re­stric­tions. In ad­di­tion, cre­at­ing a mon­it­or­ing tool that logs active sub­scribers to Mes­sage Chan­nels can be a useful sys­tems man­age­ment tool.

事件消息通常在发布，因为多个依赖者通常对一个事件感兴趣。订阅者可以是持久订阅者，也可以是非持久订阅者，请参阅第 10章“消息传送端点”中的持久订阅者。如果订阅者应确认通知，请使用Request-Reply，其中通知是请求，确认是回复。将每条消息存储在发布-订阅通道上直到所有订阅者都使用该消息可能需要大量的消息存储。为了帮助缓解此问题，发送到发布-订阅通道的消息可以使用消息过期。

An Event Mes­sage is usu­ally sent on a Pub­lish-Sub­scribe Chan­nel be­cause mul­tiple de­pend­ents are often in­ter­ested in an event. A sub­scriber can be dur­able or non­dur­able­see Dur­able Sub­scriber in the Chapter 10, "Mes­saging En­d­points." If no­ti­fic­a­tions should be ac­know­ledged by the sub­scribers, use Re­quest-Reply, where the no­ti­fic­a­tion is the re­quest and the ac­know­ledg­ment is the reply. Stor­ing each mes­sage on a Pub­lish-Sub­scribe Chan­nel until all sub­scribers con­sume the mes­sage can re­quire a large amount of mes­sage stor­age. To help al­le­vi­ate this issue, mes­sages sent to a Pub­lish-Sub­scribe Chan­nel can use Mes­sage Ex­pir­a­tion.

[查看全宽]
topic topic = // 通过JNDI获取主题
TopicConnectionFactoryfactory = // 获取连接工厂
通过 JNDI
TopicConnection连接=factory.createTopicConnection();
TopicSession 会话 = connection.createTopicSession(true,
会话.AUTO_ACKNOWLEDGE);
TopicPublisher 发布者 = session.createPublisher(topic);

Message message = session.createTextMessage("消息内容
信息。”）;

发布者.publish(消息);

[View full width]
Topic topic = // obtain the topic via JNDI
Top­ic­Con­nec­tion­Fact­ory fact­ory = // obtain the con­nec­tion fact­ory
 via JNDI
Top­ic­Con­nec­tion con­nec­tion = fact­ory.cre­at­eTop­ic­Con­nec­tion();
Top­ic­Ses­sion ses­sion = con­nec­tion.cre­at­eTop­ic­Ses­sion(true,
 Ses­sion.AUTO_AC­KNOW­LEDGE);
Top­icPub­lisher pub­lisher = ses­sion.cre­ate­Pub­lisher(topic);

Mes­sage mes­sage = ses­sion.cre­at­e­Text­Mes­sage("The con­tents of the
 mes­sage.");

pub­lisher.pub­lish(mes­sage);

[查看全宽]
topic topic = // 通过JNDI获取主题
TopicConnectionFactoryfactory = // 获取连接工厂
通过 JNDI
TopicConnection连接=factory.createTopicConnection();
TopicSession 会话 = connection.createTopicSession(true,
会话.AUTO_ACKNOWLEDGE);
TopicSubscriber 订阅者 = session.createSubscriber(topic);

TextMessage 消息 = (TextMessage) 订阅者.receive();
字符串内容 = message.getText();

[View full width]
Topic topic = // obtain the topic via JNDI
Top­ic­Con­nec­tion­Fact­ory fact­ory = // obtain the con­nec­tion fact­ory
 via JNDI
Top­ic­Con­nec­tion con­nec­tion = fact­ory.cre­at­eTop­ic­Con­nec­tion();
Top­ic­Ses­sion ses­sion = con­nec­tion.cre­at­eTop­ic­Ses­sion(true,
 Ses­sion.AUTO_AC­KNOW­LEDGE);
Top­ic­Sub­scriber sub­scriber = ses­sion.cre­ate­Sub­scriber(topic);

Text­Mes­sage mes­sage = (Text­Mes­sage) sub­scriber.re­ceive();
String con­tents = mes­sage.get­Text();

数据类型通道

Datatype Channel

应用程序使用消息传递来传输不同类型的数据，例如不同类型的文档。

An ap­plic­a­tion is using Mes­saging to trans­fer dif­fer­ent types of data, such as dif­fer­ent types of doc­u­ments.

所有消息都只是消息系统定义的相同消息类型的实例，并且任何消息的内容最终都只是一个字节数组。虽然这种简单的结构（字节束）对于消息传递系统能够传输消息而言足够具体，但对于接收者能够处理消息内容而言，它还不够具体。

All mes­sages are just in­stances of the same mes­sage type, as defined by the mes­saging system, and the con­tents of any mes­sage are ul­ti­mately just a byte array. While this simple struc­turea bundle of bytesis spe­cific enough for a mes­saging system to be able to trans­mit a mes­sage, it is not spe­cific enough for a re­ceiver to be able to pro­cess a mes­sage's con­tents.

接收者必须知道消息内容的数据结构和数据格式。结构可以是字符数组、字节数组、序列化对象、XML文档等。格式可以是字节或字符的记录结构、序列化对象的类、XML 文档的模式定义等。所有这些知识都被宽松地称为消息类型，指的是消息内容的结构和格式。

A re­ceiver must know the mes­sage con­tent's data struc­ture and data format. The struc­ture could be char­ac­ter array, byte array, seri­al­ized object, XML doc­u­ment, and so on. The format could be the record struc­ture of the bytes or char­ac­ters, the class of the seri­al­ized object, the schema defin­i­tion of the XML doc­u­ment, and so on. All of this know­ledge is loosely re­ferred to as the mes­sage's type, re­fer­ring to both the struc­ture and format of the mes­sage's con­tents.

接收者必须知道它正在接收什么类型的消息，否则它不知道如何处理它们。例如，发送者可能希望发送不同的对象，例如采购订单、报价和查询。然而，接收器可能会采取不同的步骤来处理每一个，因此它必须知道哪个是哪个。如果发送方只是通过单个消息通道将所有这些发送到接收方，则接收方将不知道如何处理每一项。

The re­ceiver must know what type of mes­sages it's re­ceiv­ing, or it won't know how to pro­cess them. For ex­ample, a sender may wish to send dif­fer­ent ob­jects such as pur­chase orders, price quotes, and quer­ies. Yet, a re­ceiver will prob­ably take dif­fer­ent steps to pro­cess each of those, so it has to know which is which. If the sender simply sends all of these to the re­ceiver via a single mes­sage chan­nel, the re­ceiver will not know how to pro­cess each one.

混合数据类型

Mixed Data Types

发送者知道它正在发送什么消息类型，那么如何将其传达给接收者呢？发送者可以在消息的标头中放置一个标志（请参阅格式指示符），但接收者将需要一个 case 语句。发送方可以将数据包装在命令消息中，对于每种类型的数据使用不同的命令，但是当消息试图做的只是将数据传输到接收方时，这会告诉接收方如何处理数据。

The sender knows what mes­sage type it's send­ing, so how can this be com­mu­nic­ated to the re­ceiver? The sender could put a flag in the mes­sage's header (see Format In­dic­ator), but then the re­ceiver will need a case state­ment. The sender could wrap the data in a Com­mand Mes­sage with a dif­fer­ent com­mand for each type of data, but that pre­sumes to tell the re­ceiver what to do with the data when all that the mes­sage is trying to do is trans­mit the data to the re­ceiver.

处理项目集合时，会出现与消息传递不同的类似问题。该集合必须是同类的，这意味着所有项目都是相同的类型，以便处理器知道项目的类型是什么以及如何操作它。许多集合实现并不强制所有项目都属于特定类型，因此程序员必须设计代码以确保集合中的所有项目都属于同一类型。否则，可以将不同类型的项目添加到集合中，但处理这些项目的代码将不知道如何操作每个项目，因为它不知道特定项目实现的类型。

A sim­ilar prob­lem­one sep­ar­ate from mes­sagin­goc­curs when pro­cess­ing a col­lec­tion of items. The col­lec­tion must be ho­mo­gen­eous, mean­ing that all of the items are the same type, so that the pro­cessor knows what an item's type is and thus how to ma­nip­u­late it. Many col­lec­tion im­ple­ment­a­tions do not force all of the items to be of a spe­cific type, so pro­gram­mers must design their code to ensure that all of the items in a col­lec­tion are of the same type. Oth­er­wise, items of dif­fer­ent types can be added to a col­lec­tion, but the code pro­cess­ing those items will not know how to ma­nip­u­late each one be­cause it won't know what type a par­tic­u­lar item im­ple­ments.

同样的原则也适用于消息传递，因为通道上的消息同样必须属于同一类型。最简单的解决方案是所有消息都采用相同的格式。如果格式必须不同，则它们都必须有可靠的格式指示符。虽然通道并不强制所有消息都属于同一类型，但接收者需要它们是同一类型，以便知道如何处理它们。

The same prin­ciple ap­plies to mes­saging be­cause the mes­sages on a chan­nel must like­wise all be of the same type. The simplest solu­tion is for all of the mes­sages to be of the same format. If the formats must differ, they must all have a re­li­able format in­dic­ator. While the chan­nel does not force all mes­sages to be of the same type, the re­ceiver needs them to be so that it knows how to pro­cess them.

通过对每种数据类型使用单独的数据类型通道，给定通道上的所有消息将包含相同类型的数据。发送者知道数据的类型，需要选择适当的通道来发送数据。接收者知道数据是通过哪个通道接收的，也就知道它是什么类型。

By using a sep­ar­ate Data­type Chan­nel for each type of data, all of the mes­sages on a given chan­nel will con­tain the same type of data. The sender, know­ing what type the data is, will need to select the ap­pro­pri­ate chan­nel to send it on. The re­ceiver, know­ing what chan­nel the data was re­ceived on, will know what type it is.

如图所示，由于发送方要发送三种不同类型的数据（采购订单、报价和查询），因此应该使用三种不同的通道。发送项目时，发送者必须为该项目选择适当的数据类型通道。当接收一个项目时，接收者根据接收该项目的数据类型通道知道该项目的类型。

As shown in the fig­ures, since the sender wants to send three dif­fer­ent types of data (pur­chase orders, price quotes, and quer­ies), it should use three dif­fer­ent chan­nels. When send­ing an item, the sender must select the ap­pro­pri­ate Data­type Chan­nel for that item. When re­ceiv­ing an item, the re­ceiver knows the item's type be­cause of the data­type chan­nel on which it re­ceived the item.

正如消息通道中所讨论的，通道很便宜，但它们不是免费的。应用程序可能需要传输许多不同的数据类型，太多以至于无法为每个数据类型创建单独的数据类型通道。在这种情况下，多个数据类型可以通过为每种类型使用不同的选择性消费者来共享单个通道。这使得单个物理通道就像多个逻辑Datatype Channel一样（一种称为多路复用的） 。数据类型通道解释了为什么通道上的所有消息必须具有相同的格式，规范数据模型解释了企业中所有渠道上的所有消息应如何遵循统一的数据模型。

As dis­cussed under Mes­sage Chan­nel, chan­nels are cheap, but they are not free. An ap­plic­a­tion may need to trans­mit many dif­fer­ent data­types, too many to create a sep­ar­ate Data­type Chan­nel for each. In this case, mul­tiple data­types can share a single chan­nel by using a dif­fer­ent Se­lect­ive Con­sumer for each type. This makes a single phys­ical chan­nel act like mul­tiple lo­gical Data­type Chan­nels (a strategy called mul­ti­plex­ing). Whereas Data­type Chan­nel ex­plains why all mes­sages on a chan­nel must be of the same format, Ca­non­ical Data Model ex­plains how all mes­sages on all chan­nels in an en­ter­prise should follow a uni­fied data model.